Codex, Claude, and shell — developers want one handoff layer, not three sessions

If you do any serious AI-assisted coding, you've probably already arrived at the multi-tool setup. Codex CLI or one of its cousins for autonomous tasks. Claude Code for chatty refactors. The shell for the parts neither AI does well. Maybe Cursor in another window. Maybe a custom MCP client for some specific job.

Each tool is good at its slice. The cost is at the seams between them.

You hand a half-finished idea from Claude to Codex; Codex doesn't have the context. You finish a Codex task and want to review it in Claude; you have to paste the diff and re-explain the goal. The shell knows neither one. The user is doing the handoff in their head, every time, dozens of times a day.

The real product gap isn't "a better tool." It's the handoff layer — the surface that keeps decisions, commands, and next steps aligned across whatever tools are open.

What a handoff layer would actually carry

A useful handoff layer carries the things that survive the tool change. A few specific kinds:

Decisions. "We decided to use approach X." "We chose not to upgrade Y." Whichever tool the user is in next, the decision should be in scope.

Current state. Which files are being edited, which branch, which test is being run, which error is being investigated. The next tool should know.

Next steps. "Once Codex finishes the refactor, run the test suite and check whether the migration is needed." The state and the plan move together.

Recent shell commands. What the user just ran in the terminal, what the output was, what produced the current state of the working tree.

Active prompts. The system prompt or instruction the user established at the start of the session. Whichever tool the user opens next should inherit it.

These are the artifacts the user is mentally re-loading every time they switch tools. A handoff layer carries them automatically.

Where this already exists, sort of

A few partial implementations of this exist in the wild.

Project files like CLAUDE.md or AGENTS.md. These hold long-lived project conventions that any compatible AI tool can read. They're the closest thing to a stable handoff for standing context.

Vaults and MCP memory servers. A few products already let you store memories that surface across multiple AI clients. They handle decisions and standing prompts, less so the active state.

Terminal multiplexers + screen capture. Some Codex/Claude setups try to expose the shell's recent commands and output to the model. Useful, but per-tool rather than shared.

Manual handoff notes. The user writes a short "here's where I left off" note and pastes it into the next tool. Works, but expensive.

None of these are the complete handoff layer. They're hints of it.

What the complete handoff layer needs

For the handoff to actually feel seamless, a few capabilities have to come together.

Cross-tool reach

The handoff layer has to be reachable from every tool the user runs. Codex, Claude Code, Cursor, shells, GUIs. MCP is the most plausible substrate today, because any MCP-aware tool can talk to the same server. The layer presents itself as a tool any client can invoke.

Append-friendly writes

Each tool needs a one-liner to append a fact: "decided X," "current branch Y," "next step Z." Without easy writes, the layer stays empty.

Scoped, current reads

When a new tool opens, it reads the current scope's state. Not the whole history — the current state. The handoff is "where are we now," not "what did we ever do."

Recent shell awareness

A shell-aware handoff layer captures the last N commands run in relevant shells, alongside their output. The next AI tool that opens can see what the user just did.

Manual override

The user can pin or unpin facts. They can mark a decision as "no longer current." They can clear scope when switching projects. The layer respects the user's edits.

With these in place, the handoff layer becomes the substrate the user's tools share. Switching tools is no longer re-loading state by hand.

Why this differs from a vault for memories

A vault that stores memories is a standing context substrate — the user's preferences, the project conventions, the durable facts. It changes slowly.

The handoff layer is active context — the state of the current work session. It changes fast.

The two are complementary. The vault answers "what do you know about me?" The handoff layer answers "what are we doing right now?"

Different cadences, different semantics, but they're naturally adjacent in the same substrate. A product that handles both — slow context and active context — is the cleanest shape for the multi-tool coding world.

What it does for the user

A few daily behaviors get noticeably better once a handoff layer exists.

Switching tools mid-task is free. Start an idea in Claude Code, decide it would be better as a Codex autonomous run, finish in Claude. No re-pasting state.

Recovery from a closed window is real. Close Codex by accident; the next tool you open still knows what you were doing.

Parallel agents stay aligned. Run two agents on related sub-tasks; both can read the shared handoff layer to avoid stepping on each other.

Sessions that span days resume cleanly. Yesterday's session ends, today's begins; the handoff layer has the decisions, the current branch, the next steps.

Onboarding a teammate is faster. They don't have to be told the state of the work — they read the handoff layer.

What it does for tool builders

If you build AI coding tools, the handoff layer is something to design for, not a feature to compete with.

• Read from the handoff layer at session start. Surface its current scope to the user and the model.
• Write to the handoff layer when the user takes load-bearing actions. Decisions, scope changes, completion of major tasks.
• Expose your tool's internal state to the layer in a way other tools can consume. Branch, file, recent commands, current prompt.
• Don't try to be the handoff layer. Different tools have different strengths; the layer is shared substrate, not a product surface to own.

A tool that plays this role well becomes a citizen of the user's multi-tool workflow. A tool that ignores the layer becomes a silo the user has to manually feed.

What it does for the shell

The shell is the underrated part of this story. It's where the user actually runs the code; it's where the truth lives. Any handoff layer that doesn't capture shell state is missing the part of the workflow that most determines what the next AI tool should do.

A shell-aware handoff layer:

• Knows the recent commands (the last N).
• Knows the working directory.
• Knows the current branch and the dirty state of the tree.
• Knows which background processes are running.
• Captures the output of long-running commands as the AI tools can read them.

This lets the next AI tool answer "what did the user just do in the shell?" without the user having to paste anything. A surprising amount of multi-tool friction collapses once that loop is closed.

What to build today

Until a full handoff layer ships from a major player, an interim version is buildable in a week:

1. Pick a substrate — a markdown file at a known path, a small SQLite DB, or an MCP server.
2. Define the schema: decisions, current state, next steps, recent commands, active prompt.
3. Write small tools to append: handoff decision "...", handoff next "...", etc.
4. Configure each of your AI tools to read the substrate at session start (the easiest version is to have the system prompt include the contents of the handoff file).
5. Build a shell hook that appends recent commands and outputs to the substrate automatically.

This is a poor person's handoff layer. It works. After a few days you'll notice which fields you actually use, which ones are noise, and where the substrate needs to grow.

The summary

The seams between AI tools cost more than any single tool's improvements. A handoff layer — shared decisions, current state, next steps, shell awareness — is the missing surface that turns a tangle of clients into a coherent workflow. It can be ad-hoc today and product-shaped tomorrow. Either way, the value is in the substrate that survives the tool switch.