Allows AI agents to find and resume sessions from Google Antigravity by indexing its local summaries and transcripts, returning a condensed resume payload.
Allows AI agents to find and resume sessions from OpenAI Codex by indexing its local state database and rollout logs, returning a condensed resume payload.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AMLink resume the Codex session about the paywalls audit"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that lets any AI coding agent instantly find and resume a session created in another agent.
You work across several coding harnesses — Google Antigravity, OpenCode, ZCode, OpenAI Codex — and when you hit a rate limit on one, you switch to another and keep going. The catch: every harness stores its sessions in its own corner of the disk (SQLite, JSONL, protobuf…), so the new agent starts blindly running find / grep / recursive scans just to locate the session file — burning time and tokens before any real work happens.
AMLink kills that step. A local MCP server indexes all your harnesses' sessions read-only, with zero LLM tokens, and injects a compact, ready-to-resume payload straight into the new agent's context.
┌─────────────┐ "resume the Codex session 'audit paywalls'"
│ Receiving │ ─────────────┐
│ agent │ ▼
│ (ZCode, …) │ locate_and_load_session() ┌────────────────────────────┐
└─────────────┘ 100% local search │ Read-only index │
▲ SQLite / JSONL / protobuf │ ~/.codex (state db) │
│ │ ~/.local/... opencode.db │
└──────────── compact Markdown/YAML ◀──────────│ ~/.zcode (db.sqlite) │
payload (objective, files, │ ~/.gemini (brain/) │
recent turns, next step) └────────────────────────────┘🔌 One server, four harnesses — Codex, OpenCode, ZCode, Antigravity adapters out of the box
🪙 0-token search — everything is indexed locally (native SQLite/JSONL parsing, no LLM calls, no find/grep)
🎯 Find sessions any way you remember them — session ID (partial works), exact/fuzzy title, project, or latest
📦 Compact resume payload — objective, last exchanges, files touched, todos, and the last agent message — with hard size caps per section
🧹 Noise-filtered — injected AGENTS.md blocks, <environment_context>, system reminders and sub-agent chatter are stripped out
🔒 Strictly read-only — harness databases are opened with SQLite mode=ro (with a temp-copy fallback for orphaned WALs); nothing is ever written back
🛠 Self-installing — one idempotent command wires the MCP server + anti-waste directives into all four harnesses, with .bak backups
⚡ Fast — ~0.1 s per harness to index, stdio transport (no ports, no daemon)
Related MCP server: Turbovec MCP Server
git clone <your-repo-url> AMLink && cd AMLink
uv sync # creates .venv, installs fastmcp
uv run server.py --selftest # validates all 4 adapters against your real data
uv run install.py # wires MCP configs + skills + directives (backups .bak)Then restart each harness so it picks up the server, and just ask:
"reprends la session latest" / "resume the Codex session about the paywalls audit"
uv run install.py --detect # preview targets, change nothing
uv run install.py --uninstall # cleanly remove everything it addedTool | Description |
| The main tool. |
| Quick index listing (id, title, project, last activity) to disambiguate a vague reference. |
| Unified checkpoint written to |
| Force an index rebuild (normal cache expires after 60 s or as soon as a source's mtime changes). |
Each session is condensed into a small Markdown/YAML payload — typically 4.5–8.5 KB on real data (versus a 13,500-character raw prompt or a megabyte-scale SQLite database). It contains: metadata (harness, session id, project, dates, model, git branch), the objective (the real first user message), the last exchanges, the last executed commands, files touched with per-file operation counts, remaining todos, and the last agent message as the resume point.
Deliberately excluded (this is where the token savings come from): harness-injected blocks (# AGENTS.md instructions, <environment_context>, <app-context>, system reminders), raw tool outputs and diffs (only paths + counters survive), the full message history beyond the last N exchanges, and sub-agent sessions.
|
|
| |
Initial prompt | 600 chars | 1,500 | 4,000 |
Recent exchanges | 3 × 300 chars | 6 × 600 | 12 × 1,200 |
Files listed | 15 | 40 | 100 |
Recent actions | — | 5 | 10 |
All caps are editable in config.json → payload_limits.
Harness | Index (titles, projects, dates) | Detail (messages, files) |
Codex |
| rollouts |
OpenCode |
|
|
ZCode |
|
|
Antigravity |
|
|
Notes: Antigravity's conversation .db files are opaque protobuf blobs, so AMLink never parses them — titles come from the summaries protobuf and content from the readable transcripts. Antigravity "files touched" are files mentioned in the transcript (labeled as such in the payload). Codex reasoning is encrypted by OpenAI and is not (and cannot be) injected.
install.py wires upEvery entry points to the uv-managed venv Python via absolute path, so launching works from any working directory.
Harness | File | Entry |
Codex |
|
|
OpenCode |
|
|
ZCode |
|
|
Antigravity |
|
|
Transport is stdio: each harness spawns its own instance — no ports, no shared state. Alternative launch: uv run --project /path/to/AMLink server.py.
The installer also injects strict rules so agents use the bridge instead of crawling the disk:
ZCode: skill at ~/.agents/skills/session-bridge/SKILL.md
Codex / OpenCode / Antigravity: a marked section in each AGENTS.md (~/.codex/, ~/.config/opencode/, ~/.gemini/); per-workspace alternative: copy it into .agentrules
The rules: (1) never search for a session with find/grep/recursive ls/disk scans; (2) call locate_and_load_session as soon as a previous session/ID/title from another agent is mentioned; (3) resume work immediately upon receiving the payload; (4) offer a save_active_session checkpoint before an interruption.
Everything can be overridden in config.json (~ is supported). Defaults:
Source | Linux / macOS | Windows |
Codex |
|
|
OpenCode DB |
|
|
ZCode DB |
|
|
Antigravity |
|
|
Checkpoints / cache |
| same |
On Windows use forward slashes in config.json (C:/Users/name/…); the venv Python is .venv/Scripts/python.exe (handled automatically by install.py).
uv run server.py --search "impression ticket"
uv run server.py --search latest --harness codex --detail minimal
uv run server.py --list --harness zcode --limit 10
uv run server.py --selftest
uv run server.py --detectHarness databases are opened strictly read-only (file:…?mode=ro, temp-copy fallback for orphaned WALs) — AMLink never writes to them.
~/.zcode/cli/config.json contains an API key: the installer preserves it without ever displaying it, and the MCP server never returns config file contents.
Payloads contain your own session content; nothing leaves your machine.
A harness doesn't see the server — restart it after install.py; check uv run server.py --detect and that .venv/bin/python exists (uv sync).
Session not found — refine the title, or call list_sessions; a partial ID (8 chars) is enough; call refresh_index() if the session just ended.
Odd Codex title — raw titles come from Codex's own database; the generated title (session_index.jsonl) is preferred for display, and both are searched.
Antigravity — conversation .db files are opaque protobuf; the bridge uses readable brain/ transcripts + summaries .pb. "Files touched" are transcript mentions, not a guaranteed exhaustive list.
AMLink/
├── server.py # FastMCP server (stdio) + debug CLI
├── config.json # paths + payload limits (overridable)
├── adapters/ # one adapter per harness + checkpoints
│ ├── base.py # SessionRecord, read-only SQLite helpers
│ ├── codex.py # state db + rollout JSONL
│ ├── aifamily.py # shared OpenCode/ZCode schema
│ ├── opencode.py / zcode.py
│ ├── antigravity.py # transcripts + protobuf wire walker
│ └── checkpoint.py # save_active_session
├── formatter.py # compact Markdown/YAML payload
├── indexer.py # fuzzy search (accent/case-insensitive) + mtime cache
├── install.py # integration install/uninstall (with .bak backups)
├── ROADMAP.md # improvement axes & final verdicts (decision log)
└── skills/session-bridge/SKILL.mdPlanned and rejected axes live in ROADMAP.md with their verdicts — top candidates: full-text search across session content, and cross-harness session lineage.
List indexed sessions (id, title, project, last activity). Useful to pick a session before calling locate_and_load_session.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max number of sessions (most recent first). | |
| harness | No | all | codex | opencode | zcode | antigravity | checkpoint. | all |
| project | No | optional filter by project path (substring). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. 'List' reasonably implies a read-only, non-mutating operation, and 'indexed sessions' hints that results come from an index, but the description does not explicitly state side-effect safety, freshness semantics, or any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action and output fields are front-loaded, and the usage guidance is included in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with full parameter schema coverage and an output schema, the description is nearly complete. The main gap is that 'indexed' is not elaborated, which could matter given the refresh_index sibling and potential index freshness concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description with defaults and allowed values. The tool description adds no parameter-level detail beyond context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List indexed sessions') and enumerates the returned fields (id, title, project, last activity). It also differentiates the tool from its primary sibling by framing it as a picker before locate_and_load_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: use it to pick a session before calling locate_and_load_session. It names the relevant sibling alternative, though it does not explicitly address when not to use it relative to save_active_session or refresh_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate a session from another harness and return a condensed, ready-to-resume payload (objective, recent exchanges, files touched, next step). 100% local search, zero LLM tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | session ID (partial accepted), exact or partial title, context keywords, or "latest" for the most recent session. | |
| detail | No | minimal | standard | full (condensation level). | standard |
| harness | No | one of codex | opencode | zcode | antigravity | checkpoint | auto (default: search everywhere). | auto |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, and it does well by adding concrete traits: 100% local search, zero LLM tokens, and a condensed payload with specific contents (objective, recent exchanges, files touched, next step). It does not discuss side effects or failure modes, but the operation reads as non-mutating and the output is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler, no repetition of schema fields, and the core action plus output are front-loaded. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with a fully documented input schema and an output schema, gives an agent enough to invoke the tool correctly. It could be more complete by explicitly routing to sibling tools or noting edge cases, but nothing essential to calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents query, detail, and harness with clear meanings and defaults. The description adds no parameter-level detail beyond the schema, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (locate), a specific resource (a session from another harness), and a concrete deliverable (a condensed ready-to-resume payload). It is clearly distinct from siblings like list_sessions, save_active_session, and refresh_index, which handle browsing, persisting, and indexing rather than retrieval for resumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ready-to-resume payload' and 'from another harness' implies the intended use case, and the '100% local search, zero LLM tokens' note signals a lightweight retrieval context. However, it never explicitly names alternatives or states when not to use this tool, such as pointing to list_sessions for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force a rebuild of the session index (e.g. right after a large session has just finished).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the action ('force a rebuild'), but does not mention potential side effects, cost, whether the operation is asynchronous, or if it affects other sessions. For a rebuild operation this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with zero filler. It front-loads the core action ('Force a rebuild'), then immediately offers a practical example that justifies the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, the description supplies the essential purpose and a typical invocation context. It does not elaborate on timing or blocking behavior, but the low complexity makes this a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The schema covers the empty set 100%, and the description correctly focuses on when and why to call the tool rather than on nonexistent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Force a rebuild') and a clear resource ('the session index'), distinguishing it from sibling tools like list_sessions or save_active_session. The 'e.g.' example grounds the action in a concrete scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use this tool ('right after a large session has just finished'), which implies the index may be stale or incomplete. It does not explicitly mention when not to use it or contrast it with alternatives, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a checkpoint of the current session (unified checkpoint) so another harness can retrieve it via locate_and_load_session.
Call it before stopping (rate limit reached, end of session).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | short session title. | |
| project | No | project path. | |
| summary | Yes | objective + progress state (a few sentences). | |
| next_steps | No | what remains to be done / next action. | |
| files_touched | No | paths of modified files. | |
| source_harness | No | origin harness (codex, opencode, zcode, antigravity). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It does state the core behavior: a unified checkpoint is saved so another harness can retrieve it via locate_and_load_session. However, it does not disclose side effects such as overwriting existing checkpoints, persistence details, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary action is front-loaded, and the second sentence provides the exact invocation context. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a checkpoint-saving tool, the description covers what it does, why it is used, and when to call it. The presence of an output schema covers return-value expectations, and the schema covers parameter details. It could be slightly more complete with caveats about repeated saves or overwrite behavior, but it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all six parameters clearly. The description itself adds no parameter-level detail, which matches the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Save a checkpoint of the current session (unified checkpoint)'. It also names the complementary sibling tool locate_and_load_session, making the tool's role in the workflow clear and distinguishing it from retrieval-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance: 'Call it before stopping (rate limit reached, end of session).' This tells the agent when to invoke the tool, though it does not explicitly discuss when not to use it or compare it against list_sessions or refresh_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_sessionslocate_and_load_sessionrefresh_indexsave_active_sessionScored across 4 tools
Each tool has a clearly distinct purpose: saving, listing, loading, and refreshing index. No overlap or ambiguity exists, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun snake_case pattern (locate_and_load, list, save_active, refresh). This predictable naming reduces cognitive load and improves discoverability.
With only 4 tools, the server is tightly scoped to session management. Each tool addresses a necessary step in the workflow, and none are redundant or trivial.
The set covers the full lifecycle of session persistence: save, locate, list, and maintain index. There are no obvious gaps that would prevent an agent from completing the core task of transferring sessions between harnesses.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Local-first, governed memory and session continuity for AI coding agents. No cloud, no telemetry.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Persistent memory for AI agents. Search, store, and recall across sessions.