What actually goes wrong
You describe the work to Claude Code. It reads the repo, makes the change, opens the PR. That part works — it's the reason you're using it. The part that doesn't work is everything downstream of "done": by the next session, you can't tell from any tracker what Claude actually did, what it decided along the way, or whether "done" meant it met the acceptance bar or just that the diff compiled.
Three specific complaints show up again and again from people doing this for real:
- Context disappears between sessions. What got decided last time, what's actually finished versus half-started — none of it survives a fresh context window unless someone wrote it down, and nobody did, because writing it down is the tool-switching you were trying to avoid.
- There's no safety net. An agent can close out a task without anything checking that the work met the bar it was supposed to meet. "Looks done" and "is done" get recorded as the same thing.
- The board and the repo disagree. Whatever's tracking the work — a PM tool, a spreadsheet, a TODO.md — needs a human to re-type status into it after Claude already knows the answer. The sync tax is exactly the manual step an AI coding session was supposed to remove.
The "AI updates the tracker" part isn't the hard part anymore
It's tempting to sell "the tracker updates itself from your coding session" as the answer. We're not going to, because it's no longer true that nobody else does this. Official MCP servers now ship from Jira, Linear, Notion, Asana, ClickUp, Monday, Todoist, Shortcut, Plane, Smartsheet, Wrike, GitHub Projects, and GitLab — Linear's is remote-hosted, so there's nothing to even install. If all you need is status flipped to "done" automatically, several of those tools already do it, and one of them needs zero setup.
So the question worth asking isn't "can an MCP server write to my tracker." It's "when it does, does that write actually mean what the status says it means."
What we built because that question had no good answer
Each of these exists to close one of the three complaints above — not to add breadth.
A close that's audited
Every task close records which verification gate was in force — manual, AI review, CI required, or all — and the exact criteria it was checked against. If someone overrides the gate, or amends the acceptance criteria shortly before closing, that's a separate logged event too, not a quiet bypass. "Done" stops being self-reported.
Status that isn't just typed
A task with open subtasks or an unmet dependency can't just be marked done by whoever's fastest to type it — the status you see is derived from what's actually blocking it, with a stated reason, not a field anyone can quietly set to green.
A resume point for the next session
Pin exactly where a task stood when the last session ended, so the next cold context — yours or Claude's — reads it first instead of reconstructing it from a scrollback that's already gone.
An audit trail on the task, not in the chat
Decisions you talk through with Claude get logged as a comment or a work note on the task itself, attributed to whoever (or whatever) made the call — so the trail outlives the terminal session it happened in.
We run our own work through this, on purpose
IDEA Base is tracked in IDEA Base. Every feature on this page, including this page, went through a task with acceptance criteria, a status that moved as the work moved, and a close that recorded which verification gate it passed. That's one account's worth of evidence, not a claim that it's been battle-tested at scale — we won't tell you otherwise. See the actual MCP exchange on the setup page.