DEV Community

shuo xiao
shuo xiao

Posted on

Coding agents keep losing context between tools, so I built a local-first handoff CLI

#ai #opensource #cli #devtools

The problem

I often switch between Codex, OpenCode, Cline, Claude Desktop, scripts, and terminals.

The annoying part is not starting a new tool. The annoying part is explaining the same workspace state again:

  • what changed
  • what is still pending
  • what should not be touched
  • what tests passed
  • what the next agent should read before editing

What I built

AgentContextBus (acb) is a local-first CLI for handing off workspace context between coding agents.

It saves a local handoff packet, then lets the next agent read it through:

  • paste-ready prompts
  • brief prompts
  • a local dashboard
  • JSON output
  • explicit MCP tools

First run 

npx @xiaoshuo1988/acb verify first-run
Enter fullscreen mode Exit fullscreen mode

For Chinese output:

npx @xiaoshuo1988/acb verify first-run --lang zh-CN
Enter fullscreen mode Exit fullscreen mode

A normal handoff

From the agent that has context:

acb handoff --from codex --summary "Ready for the next agent" --git
Enter fullscreen mode Exit fullscreen mode

From the receiving side:

acb receive --latest
Enter fullscreen mode Exit fullscreen mode

After the receiving agent summarizes the packet:

acb ack --latest --by opencode
Enter fullscreen mode Exit fullscreen mode

What ACB intentionally does not do

  • no hidden prompt injection
  • no traffic interception
  • no third-party client config mutation
  • no cloud sync
  • no background daemon

Why local-first

I want the user to be able to inspect the packet store, copy text manually, and decide exactly when context crosses from one agent to another.

What I want feedback on

  1. Is the handoff packet concept clear?
  2. Is verify first-run enough to understand the tool?
  3. Is receive --latest the right receiving-side command?
  4. Which client path needs the most work?
  5. Would you trust this workflow in a real project?

Repo:
https://github.com/xiaoshuo1988130/acb

Feedback discussion:
https://github.com/xiaoshuo1988130/acb/discussions/1

Top comments (1)

Collapse
 
harjjotsinghh profile image
Harjot Singh •

The list of what goes in the handoff packet is the whole insight, and you nailed it: what changed, what's pending, what should not be touched, what tests passed, what the next agent should read first. That "should not be touched" line is the underrated one, the negative constraint is the highest-value thing to carry across a handoff, because a fresh agent's most expensive mistake is confidently re-editing something a prior agent deliberately left alone. Most context tooling optimizes for "here's everything," but the real signal is the boundaries. Local-first is also the right call, handoff state is workspace-sensitive and shouldn't round-trip through someone's cloud just to tell Cline what Codex already did. I run almost this exact pattern across my own multi-tool work, durable local state plus explicit don't-do-this entries, and it's the single biggest thing keeping a long task coherent when the tool (or the context window) resets. This is core to how I think about cross-run continuity in Moonshift. When two agents touch the workspace close together, does acb handle conflicting handoffs, or is it assumed-sequential for now?