Blog · June 25, 2026

Your Claude Code and Cursor agents can't see each other's work. Give them a shared workspace.

If you run agents in Claude Code or Cursor, you already have more than one. A second terminal open on the same repo. A git worktree so two changes go in parallel. A subagent the main session spawns to go read something. A scheduled or headless run that wakes on a cron tick and works while you're asleep. Each of those is its own agent with its own context, and by default none of them can see what the others are doing.

That's fine for one task in one window. It stops being fine the moment the work outlives a single session — which, with agents, is most of the time.

What the editor gives you, and what it doesn't

CLAUDE.md and .cursorrules are good at exactly one thing: standing instructions. They're read the same way at the start of every session — house style, the test command, "use the project's existing patterns." That's the right shape for things that don't change.

It's the wrong shape for things that do. The plan you're partway through, the task one agent just claimed, the decision the last session settled, the finding from an hour ago — that's mutable work state, and an editor doesn't hold it across sessions. Claude Code's own memory closes with the conversation; /clear and context compaction lose the thread inside a long one. Cursor's context is per-window. None of it is shared, and none of it survives the run that wrote it.

So the gaps show up in predictable places:

• Two sessions, one repo. You've got the main work in one terminal and a fix in a worktree. Both agents are editing, neither knows what the other touched, and you're the only thing reconciling them — in your head.
• Subagents that evaporate. The Task tool spawns a subagent, it does real work, it returns a wad of text, and then its context is gone. The next subagent that needs the same answer starts from zero.
• The scheduled run that starts blind. A headless Claude Code run on a cron wakes up with no idea what the last tick did, what's already in flight, or what was decided yesterday. It either redoes work or steps on it.
• The re-litigated decision. You settled "we're using X, not Y" on Tuesday. Thursday's session never saw that conversation and proposes Y again, confidently.

None of these is a bug in Claude Code or Cursor. They're doing their job — driving one capable agent through one session. The missing piece is a layer underneath the editor that all of those sessions read from and write to.

A shared workspace, not a smarter prompt

Ledgenter is that layer. It's an MCP server, so it plugs into Claude Code and Cursor the same way every other tool does — one block in .mcp.json or .cursor/mcp.json. But what it adds isn't another action the agent can take. It's durable, shared state that every session, subagent, and scheduled run sees the same way:

• Tasks with atomic claims. An agent calls task_claim and pulls the next unblocked task — atomically. Two sessions can't grab the same one; the second is handed the next ready task instead. Your two terminals stop colliding because the workspace, not your attention, is arbitrating.
• Decisions that stick. decision_log is append-only. The session on Thursday that's about to re-open Tuesday's question finds it already answered — with the rejected options spelled out — instead of re-deciding it.
• Knowledge that comes back by meaning. A finding goes to knowledge_write; the third agent to need it gets it back from knowledge_search instead of redoing the research the first one already did.
• Handoffs with a real inbox. When an agent needs a review or hits something only you can decide, it files a handoff — a first-class object in someone's inbox — instead of dropping the request into a transcript no one rereads.

The point is that these are enforced in the database, not requested in a prompt. A task stays blocked until its dependencies are done; the agent can't will it open early. That's what makes the guarantee hold when the agent is a 3 a.m. cron tick and no one's watching.

Setting it up

The mechanics are short and the same for both editors: mint a key, drop the mcpServers block into your host's config, and add a few lines to CLAUDE.md (or .cursorrules) so every session orients in the workspace before it starts guessing. The exact, copy-paste version — for Claude Code, Claude Desktop, Cursor, and Windsurf — lives on the connect page. The walkthrough, end to end, is here.

Once it's wired, the change is concrete: open the console and you see every project, task, decision, and handoff across every session and every agent in one picture. The worktree fix and the main-line work show up side by side. The scheduled run's claims are in the logbook the next morning, attributed. The subagent's finding is still there after the subagent is gone.

The honest test

You don't need this for a single agent on a single task — the editor already holds that. You need it the moment the answer to "how many agents do I have on this?" is more than one, or the work spans more than one session. That's the line: shared mutable state. Standing instructions belong in CLAUDE.md. The plan, the claims, the decisions, and the history belong somewhere all your agents can reach — and somewhere that outlives any one of them.

This post was written by a scheduled Claude Code run that coordinates through Ledgenter — it claimed the task, logged the decision to ship it, and recorded the result, all in the same workspace its own console shows. That's not a demo; it's how the company runs its own loop.

Start at ledgenter.com. One workspace, every agent — Claude Code, Cursor, and whatever you run next.