Memory & context bridge

This is the part that makes V3Code Terminal different from a generic terminal agent. Two systems run underneath every session: memory, which keeps what was learned, and the context bridge, which understands how your code fits together.

The sidebar is where you see it

Press Ctrl+X then B to toggle the sidebar. It has six tabs:

Session, Files, Tasks, Index, Memory, and Team.

Note

These are tabs in the sidebar, not slash commands. For a live status summary without opening the sidebar, run /bridge or /memory-status.

Memory

The terminal writes completed session activity into the shared V3Code memory contract — the same contract the editor uses. It can keep tool activity, the files involved, failures, a checkpoint summary, and durable facts. The agent can search both the facts and the indexed handoff documents.

The Memory tab shows:

• local fact and searchable-handoff counts;
• the current session’s events, tools, files, and failures;
• decisions, quirks, patterns, and symbols;
• recent handoffs, each with a detail popup;
• team relay counts for queued, sent, received, or retrying handoffs.

The agent has a memory tool with four actions:

recallsearch

Searches relevant facts and indexed handoffs.

savewrite

Stores a durable decision, pattern, quirk, dependency, file state, symbol, or roadmap fact.

forgetwrite

Removes a selected fact.

statusread

Reports the local library and editor connection state.

Note

The local copy is authoritative. When no signed-in editor transport is attached, team handoffs stay queued locally — queued is not the same as synced to the cloud.

The project index — you choose what gets read

Open the Index tab to add source locations. You can paste a path, use your system’s folder picker, or pick a single file. V3Code scans supported source and documentation text for a preview, shows the file count and size, and waits for your confirmation before building anything. Each location can be paused, resumed, rebuilt, or removed.

The semantic index is stored at ~/.v3code/semanticdb/ and never needs a running editor.

Hard safety limits, enforced in code:

Limit	Value
Files per location	20,000
Size per file	512 KB
Filesystem entries visited	200,000
Discovery time	45 seconds

System roots, drive roots, and your entire home folder are blocked outright. Dependency, build, credential, secret, and ignored paths are excluded.

If the agent is asked to search semantically before you’ve approved any location, it asks you to open the Index tab. It does not silently scan your project.

The bridge tool

The agent’s bridge tool has six actions:

Action	What it does
semantic_search	Searches only your approved Index locations, by behavior or intent.
symbol_search	Finds declarations with identifier-aware matching.
references	Finds call sites and usages, grouped by file.
trace	Estimates the blast radius of a file or symbol through the Beast sidecar.
status	Reports built-in index, Beast, memory, and editor state.
reindex	Rebuilds the structural index after large changes.

The built-in structural index is created on first symbol or reference use. The optional Beast index adds deeper shared indexing with the editor. If Beast isn’t installed, symbol search and references fall back to the built-in index, and deep trace tells you what’s missing instead of pretending it ran.

Team Flight Deck

The Team tab shows the lead session with its real child sessions: agent and model identity, busy state, retry or approval state, worktree branch, changed-file count, and last update. Clicking an agent opens that session.

The handoff rail never infers success:

• WORKTREE says shared checkout until a connected worktree is attached.
• VERIFY says not recorded until a captured verification command finishes.
• HANDOFF says checkpoint ready only once the local memory library actually contains that checkpoint.

Those are evidence states, not errors.

Related

The editor side of these systems is documented in Context Bridge, Memory, and Semantic index.