# 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:

### recall

Searches relevant facts and indexed handoffs.

### save

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

### forget

Removes a selected fact.

### status

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](/editor/context-bridge), [Memory](/editor/memory), and [Semantic index](/editor/semantic-index).