Launched this week
scritty
Shared, searchable memory for every AI coding agent
135 followers
Shared, searchable memory for every AI coding agent
135 followers
scritty is a terminal emulator that captures every CLI agent's conversation (Claude, Codex, Copilot, Antigravity, Ollama), indexes it into one searchable corpus you control, and serves it back to your agents over MCP and to you over the CLI. One session across desktop, browser, and mobile. Your captures stay on your machine.
Interactive
Free Options
Launch Team / Built With
scritty
The immutable-transcript plus redact-at-share-boundary split makes sense, but the local index still holds plaintext secrets at rest — so any agent or MCP client with read access to the data dir (or a synced backup) can pull an old key straight out of search. Is there any at-rest encryption on the local store, or is the model explicitly 'your disk is the trust boundary'? And can the session-to-project scope widening be gated per MCP client, so one agent can't request the whole corpus?
@scritty_dev Shared memory for agents is such a practical problem. Are you seeing devs use this mainly for context persistence or also for knowledge discovery between different agent runs?
scritty
@clquek great question, it really depends on the dev and their workflow (or team workflow) single agent devs will lean more on the context persistence and RRF retrieval for lexcial/semantic recall whereas multi agent users/teams utilize this more for not just knowledge discovery/sharing but also an often overlooked key layer in continuity so that their different agent runs are seamless vs manual clunky transfer/hand-offs
The context loss between agents is real and nobody talks about it
enough. I've been using Claude Code heavily and the moment you hit
a usage limit mid-session the mental overhead of rebuilding context
somewhere else is brutal — you spend the first 10 messages just
catching the new agent up instead of actually solving the problem.
The MCP angle is the part that makes this different from just
"searchable logs." Agents querying each other's past turns rather
than starting cold is a genuinely different model. Curious how the
retrieval quality holds up on longer sessions — does it surface
the right past context or do you find yourself still needing to
manually point it at the right conversation?
Also the prompt.toml injection is underrated. Maintaining consistent
rules and persona across agent switches without copy-pasting is
something I'd use daily.
scritty
@l_build appreciate this! retrieval quality question is the real one cause searchable logs alone aren’t enough. under the hood it’s hybrid keyword + vector retrieval over captured exchanges, exposed back to agents over MCP, so the goal is to surface the few prior turns that actually matter instead of making you reconstruct the session by hand. it might seem counter-intuitive but I let the retrieved results shape the context in the prompt vs try to shove all (what I deem) relevant context in myself
The case I would test hard is stale or wrong memory, not just recall. If one agent records a bad debugging hypothesis and another agent asks about the same repo tomorrow, can I mark that capture as superseded or incorrect so it stops being retrieved?
For coding agents, I would want each memory hit to show source session, repo/branch, timestamp, and whether it was later contradicted. Local storage is a good default, but stale local facts can still send the next agent down the wrong path.
scritty
@tang_weigang agreed bad memory can be more dangerous than no memory. there are levers like provenance, relevance/confidence decay, and mark_noise to demote bad hits, but I wouldn’t claim there’s an explicit “superseded/contradicted” the idea is the substrate improves upon itself dynamically via these tools rather than hard deletes.
The part that sells me is that it sits as the terminal the agents already run in and captures passively — the 'bring the new session up to speed' dance is exactly the tax I want gone. Since captures stay local, does secret/token redaction happen at capture time, or does raw terminal output (API keys, env dumps) land in the searchable index as-is? And when an agent pulls context back over MCP, is retrieval scoped per-project/repo, or does it serve the whole corpus so unrelated work bleeds into the prompt?
scritty
@hi_i_am_mimo 1.) no capture-time redaction raw output lands as-is, but it's all local/no-telemetry, and I'd rather redact at share boundary (encrypted sidecar) than rewrite actual transcript as I treat it as immutable. that said I will happily roadmap this as a native feature vs relying on user. my methodology is a DRY wrapper around the same code for CLI and MCP so both you and your agent(s) can do it. 2.) auto-injected context is session-scoped by default, so unrelated work doesn't bleed in; widening to project/global is opt-in, and the hard "never mix" boundary is separate tenants/data dirs.
This tracks. The wall I hit doing hybrid retrieval over raw terminal exchanges is that tool output, the file dumps and stack traces, dominates the keyword side and matches great while carrying zero reasoning, and the actual 'why' lives in the model prose the vector side catches. Ended up down-weighting tool-output spans so the small budget didn't get eaten by noise that scored relevant. Do you tag span type at capture, or leave it to the ranker?
scritty
@dipankar_sarkar bingo. tool output matches great on keyword and carries zero 'why' cause reasoning lives in prose the vector side catches. down weighting after the fact works but you're making ranker rederive span type on every query (which is wasteful and query order dependent) so we tag at capture. content gets classified into normal/thinking/tool-call by structural parsers + noise pass that strips tui chrome and pure status/tool call rows before they ever hit index. so span type is a stored property, not a per query guess. the ranker then does query specific part signed EMA down rank on explicit noise marks and axis-aware decay, on top of corpus that's already typed.
split we landed on was capture decides what a span is (stable, structural); ranker decides what it's worth for this query (dynamic, feedback driven). trying to do first job in ranker is the budget eaten by noise problem you hit cause you can't cheaply re-classify at query time, so you end up hand weighting. tag once, up front, and small budget goes to reasoning instead of stack traces.
The cross-tool angle hides a mismatch I keep hitting: memory written by one model's sense of what mattered, read back by a different one. A summary of Claude's own debugging reasoning isn't always legible to Codex, which had a different plan for the same repo. You mentioned raw turns stay the source of truth, which is the right call, so the pressure moves to retrieval budget: what's the cap on turns pulled per query? Pull back 15 old sessions and you've rebuilt the exact context wall you're routing around.
scritty
@dipankar_sarkar correct. so retrieval budget is intentionally small not “replay 15 sessions.” goal is a few high-signal exchanges/chunks so you don’t recreate same context wall you were trying to escape. agreed on model mismatch point too: codex should read claude’s raw exchange text, not claude’s self-summary of what mattered. raw turns stay source of truth; summaries are a derived helper.
how does it actually capture the conversation from agents like Codex and Copilot, do you have to wrap the calls or does it hook into the terminal session itself?
scritty
@beyzaokhan works by being the terminal the agents run inside, not depending on vendor API(s). scritty detects active agent from process itself, captures exchanges in that terminal session, tags by provider, and indexes them locally. important to me because I wanted memory layer upstream of vendor lock-in and avoid dependency on things like spinners that are subject to UI updates making detection at 1 level down brittle at best