112 days late

01The number that reframes everything

The story I told myself for three weeks was the familiar one: I was building something, and the platform vendor shipped it out from under me. It is a comfortable story. It casts you as unlucky rather than careless.

Then I actually checked the dates.

days between Anthropic shipping the thing and me starting to build it.

I am writing this down because the forty-minute version of this check is easy to describe and easy to reuse, and because the 22 days were not wasted — just not in the way I planned. Both halves are below, with the data.

02What I actually built

A native macOS menu-bar app. Three things it does: watch every Claude Code session on the machine, collect risky operations into one approval console, and host sessions directly in an embedded terminal.

Twelve delivery stages, all with written acceptance contracts. Here is the shipping record — dates are the day each stage was accepted, not the day work began.

Size, measured not estimated

I mention the size not to impress anyone. I mention it because the point of this article is that all of it happened after the thing already existed, and volume of work is exactly what makes that failure invisible from the inside. Every one of those 22 days felt productive. Most of them were, locally. None of them were, strategically.

03The audit: 48 features, line by line

On 2026-08-24 I stopped building and did the check I should have done on day zero. I took the 48 features from my own internal feature matrix — the authoritative one, so I could not cherry-pick — and went through Anthropic's current documentation feature by feature.

Evidence rules, in order of weight: official documentation text first; release notes and reporting only to establish when something shipped; public issue-tracker status only to establish that something does not yet exist, which is stronger evidence than documentation silence.

What the desktop redesign took

These are the ones that hurt, because they were my stages 5, 7 and 10 — the load-bearing ones:

• Per-session git worktree isolation. Mine was stage 7. Theirs defaults to <project-root>/.claude/worktrees/, has a configurable location and branch prefix, a .worktreeinclude file for pulling gitignored files like .env into the worktree, and auto-archives when the PR merges. Theirs is more complete than mine.
• Integrated terminal, file editor, split panes, drag-and-drop layout. My stage 5.
• App preview pane and external site browsing. My stage 10, which I had not even started.
• An execution-target picker. Local / Cloud / SSH / WSL, chosen when you start a session. I had decomposed this into five stages (Y1–Y5) and finished two of them. It is a dropdown they shipped in April.
• A usage ring showing per-session context consumption and plan usage for the period. My context meter, plus a layer I did not have.
• Session sidebar with filtering by status, project, and environment, and grouping by project.

What Remote Control took

Remote Control connects a local CLI session to claude.ai/code and the mobile apps. Two lines from the official documentation:

• /config offers "Push when actions required" — for "permission prompts and questions."
• "Claude Code keeps permission prompts and AskUserQuestion questions open until you answer them."

So approving a permission from your phone, and answering a multiple-choice prompt from your phone, are both free and official. Worth noting: I had explicitly declared remote answering of multiple-choice prompts a red line we will never cross. Anthropic just shipped it. On that specific point they were more aggressive than I was willing to be, which is its own kind of feedback about my product instincts.

What survived, and why

04How I missed it for 132 days

Here is the part I find genuinely useful, because the failure is specific and repeatable rather than "I should have researched more."

I did research. On 2026-08-08 — day 5 of the project — I ran a competitive check that was, by its own standards, rigorous. I pulled the official documentation rather than trusting secondhand write-ups. I found two research summaries that contradicted each other about whether you could approve permissions from a phone, went to the source, and established that you could — and that the summary claiming otherwise was stale. I enumerated eight hard limits of Remote Control. I deleted two of my own selling points on the spot because the evidence killed them.

The method was fine. The scope was drawn wrong.

The reusable form of the lesson:

• Scope a competitive check by the opponent's product lines, not by the line you are worried about. Anxiety is a terrible index. Read their whole changelog, not the part that maps onto your fear.
• Do it before the first commit, then on a schedule. Mine happened on day 5 and then never again for 16 days — during which I shipped nine stages. A recurring calendar entry would have caught it.
• Write the result into the repo, not into a chat log. My August 8 findings did land in a spec file, which is why I could reconstruct exactly what I checked and what I did not. That part worked. Had it been a conversation, this article would have no evidence in it.

There is a smaller, more embarrassing corollary. Four months of platform releases changed the nature of at least 18 features in my product, and my project documentation contains no trace of any of it. I have 6,202 lines of design docs and a defect genealogy going back to day one, and not one line saying "the platform shipped X, here is what it means for us." I instrumented my code exhaustively and my market not at all.

05What the 22 days actually bought

Not a product. What I got instead was a set of engineering results with numbers attached, and those numbers turned out to be more transferable than the code.

The review economics

For stages 4 through 8 I ran multi-agent code review rounds — fan out reviewers across dimensions, then adversarially verify each finding. I kept the receipts.

Three findings fell out of that table that I did not expect:

1. Two thirds of what review agents raise is not real

Stage 8, round one: 42 findings raised, 14 survived adversarial verification. A 33% hit rate. Two thirds of the spend went into refuting problems that did not exist. The 28 that got knocked down were almost entirely pure code-reading inferences — "this looks like it would break."

2. The findings that mattered came from running, not reading

Both CRITICALs in that same stage came from execution, not analysis:

• One had an actual crash report on disk — AgentCompanion-2026-08-10-131832.ips. A null inside a tool's input JSON reached dataWithJSONObject and aborted the process.
• One was measured with ps: 20.3% CPU still burning after the panel was closed, against 0.5% with animation off. Nobody reads their way to that number.

Later I ran two entire stages — X and 11 — with zero review agents, and they still surfaced real crashes and real latent defects, because the work involved actually running the thing. By my count this pattern has now held five separate times in one project.

3. Reviewing the fix code always found a critical. Five stages, no exceptions

If you take one operational thing from this article, take this: a fix is not a smaller change than the thing it fixes. Review it like new code.

4. One module produced most of the criticals — and the root cause was undecidable

The injection gate — the component that decides whether it is safe to send a keystroke into a live terminal — produced more criticals than anything else in the project. Two in stage 5, two more in stage 5's second round (oscillating between fail-open and fail-closed), and in stage 7's third round it locked itself: the app blocked its own Enter key, permanently stalling three automation chains, with no dialog visible on screen to explain why.

The root cause is written into my own notes and it is not a bug: the gate is a lexical predicate. It matches strings to decide "is there a prompt on screen right now." That question is not decidable by string matching, so no number of review rounds fixes it — each round just pushes you to the next counterexample. Some defects are not defects. They are the shape of the design.

06Six incidents, dated

These are the ones I would tell a friend about. Each is in the project's defect genealogy with a date, because writing them down was a rule.

2026-08-20 — a symlink ate 823MB and 15 transcripts, permanently

A frozen test corpus, 823MB, gitignored, therefore not checked out into git worktrees. The fix was to symlink it from the main tree. The fix became the bomb: a .gitignore pattern written with a trailing slash matches directories and does not match symlinks, so the symlink got committed. After merging, a checkout in the main tree dropped a self-pointing symlink at that path and cleared the real corpus — git treats ignored files as expendable. 15 transcripts gone for good.

The tell was that the failure did not look like a missing fixture. It looked like a broken product: "181 work threads (ground truth 178) / 0 continuation chains / ai-title coverage 0 of 181." Absurd but specific numbers. The .gitignore now carries both the slashed and unslashed pattern, and the repair command is guarded by [ -e … ] || so it is a no-op in the main tree.

2026-08-20 — macOS quietly mangles non-ASCII environment variables

When the app relaunches itself from its bundle via NSWorkspace, non-ASCII environment variable values get reinterpreted as Latin-1. My project path contains Chinese characters, so 学习 arrived as å­¦ä¹. The isolation override silently failed and fell back to the real directory — while an ASCII-valued variable in the same launch worked perfectly. Test fixtures now live at ASCII-only paths, and the criterion asserts the override actually took effect.

2026-08-11 — the binary fingerprint gate caught a real one on day one

Every regression run starts by asking the running app for its binary fingerprint and refusing to continue if it does not match the build on disk. It caught a genuine "you did not actually swap the binary" the first time it ran. The failure mode it prevents is the nastiest kind: every subsequent test passes, against the old code, with no errors anywhere. The cause turned out to be mundane — an open terminal pane triggers a quit-confirmation dialog that silently blocks the kill, so the restart looks successful.

Amusingly, the first version of the fingerprint criterion was itself wrong: it ignored that codesign --force rewrites the binary in place, so the two sides were permanently 480 bytes apart.

2026-08-21 — another session swapped the binary mid-regression

One machine, one app instance, one port. Two Claude Code sessions working in parallel on the same repo, each with its own build. Whoever launches the app wins, and the other side's evidence is all invalid. Cost: a full regression run discarded halfway. The rule that came out of it is deliberately strict — handoffs count only on an explicit ping at both start and end. Reachability, uptime, fingerprints, "they've been quiet a while" — none of those count as a handoff.

Undated but recurring — I misjudged a running process as my own test fixture

I once identified a process as a leftover regression harness and killed it. It was the user's live work. The rule now: never kill, restart, or replace any running process without asking first, and by default assume every running process on the machine belongs to someone else.

2026-08-19 — the criterion that "passed" because it had no data

A screenshot criterion used screencapture without screen-recording permission. It captured nothing. The criterion counted "no data" as "no change" and printed a green check. This sits in a whole family I ended up cataloguing as fake evidence: verification paths that route around the mechanism they claim to test. An offscreen redraw that reported "correct" while the real render function was never called. An animation test where the window was occluded, the gate correctly closed, all 16 frames came out identical — and the criterion nearly filed correct behaviour as a fault.

07The rules I'm keeping

Seven things earned their place. I state them the way they are written in the repo, because the wording is load-bearing.

1. Every new criterion must be made to fail on purpose first. Break the thing it tests, watch it go red, then fix it. An assertion never observed failing is not an assertion. This project logs its red proofs — stage N had 56 of them, stage Y2a had 54, all hitting.
2. Static checks are not behavioural evidence. Learned expensively: a gate-detection layer in this codebase matched nothing at all for two entire stages while its static check stayed green. Every lexical predicate must be paired with a runtime case.
3. When a test goes red, first decide: product defect or rotten fixture? Fixture rot is the normal case, not the exception — hardcoded search terms that expired, a regex where All|Bulk matched the "All" inside "Allow for This Session", a test binary path pointing into a directory that gets cleaned.
4. One idempotent, sub-second evidence command per acceptance criterion, written when the stage starts. Retrofitted evidence is not evidence — you write it to pass.
5. Resolve spec ambiguity at kickoff, in writing, in a comment at the top of the code, pinned by a test case. Not in a chat message. Chat messages do not survive.
6. Overwrite the status document; never append. One file, under 80 lines, describing only right now: current stage, what was finished, what is next, what is unresolved. History goes to an archive and is never rewritten.
7. Acceptance criteria are a contract. No measurable evidence means not done. No checking boxes you cannot prove. When something is missing, write down what is missing.

08What I'm doing with it

Not shutting it down. Repointing it.

The audit says the honest position is not "a control panel for Claude Code" — that is a race against a vendor who is inside the process, has all the information, and moves faster. It is "one approval console for every coding agent." That target sits in their structural blind spot: they will not manage Codex, ever.

The useful thing about that repositioning is that it needs no new features. The cross-vendor line was already underway — stage 11 emptied the core layer of brand literals, stage 12a added Codex as the second provider, stage 13 targets a third. What it needs is stopping four other things: the browser pane, the diff and task tabs for my own sessions, the mobile terminal mirror, and most of the execution-target work.

There is also a competitive fact I did not have before the audit: the cross-vendor menu-bar niche is no longer empty. There are several tools tracking Claude Code and Codex sessions from the menu bar now, one of which explicitly claims to cover CLI, Xcode, desktop app and Codex, and one of which is already charging for it. Every one of them stops at usage metering. Not one touches permission requests — because that requires hooking the permission channel, building a risk model, and handling timeout policy. The unoccupied square is the intersection, not either axis.

And a small one that matters more than it should: my dispatch feature has the same name as an official Anthropic feature that does an adjacent thing. That needs to change.

09Where this article is soft

An audit that does not say where it is weak is marketing.

• "Not in the documentation" is not "does not exist." Most of the 15 survivors are judged on documentation silence. Vendors ship faster than they document. The approval-console claims are the most exposed to this.
• I did not install the official desktop app and click through it. Every judgement about their capabilities comes from documentation text. The gap between "documented" and "actually good" is unmeasured in both directions.
• The 18/15/15 split is mine. I chose the granularity of the 48 features and I drew the line between "partial overlap" and "replaced." Someone else would get different numbers. Treat it as an order of magnitude.
• The review-economics numbers come from my own delivery notes, written at the time but by the person being measured. Stage 8's two rounds did not record per-round agent counts, which is why the total is "about 190."
• The competitor claims are unverified. I read their marketing; I did not install them. If the one claiming to see CLI sessions actually does, the second-ranked moat is weaker than I said.
• One thing I did not check at all: whether anybody wants any of this. Twenty-two days, zero users. The audit measures uniqueness, not demand — and 15 unique features that nobody has asked for is not obviously better than 18 replaced ones.

10Data appendix

Everything numeric in this article, with how it was obtained. All timestamps are local time, UTC+08:00.

Publication record

Project timeline, exact

Commits per day

Verification volume

Two of those rows are deliberately unflattering. A stage that reports "all green" while quietly skipping things is worth less than one that reports 5 of 7 and says which 2 and why. That was the rule, so the numbers here follow it too.

11Sources

Official documentation — the basis for every capability judgement

• Desktop application — the session sidebar and its filters, per-session worktrees, split panes, usage ring, permission-mode table, tasks pane, cross-session messaging, cloud and SSH environments; and the passage stating that Claude does not see sessions started from the terminal CLI or the VS Code extension
• Remote Control — answering permission prompts from a phone, the Push when actions required toggle, "there is no per-event configuration," where transcripts are stored, and the conditions that disable Remote Control entirely
• Worktrees · Permission modes · Desktop scheduled tasks

Release dating

• Anthropic Rebuilds Claude Code Desktop App Around Parallel Sessions — 2026-04-14
• Claude Code Desktop Redesign: Multi-Sessions + Routines
• Push notifications in v2.1.110 — 2026-04-16

Public issue tracker — used only to establish absence

• Desktop app sidebar should show CLI-created sessions

Companion piece

• The full feature-by-feature audit (Chinese) — all 48 rows, the evidence for each judgement, and the roadmap consequences. This article is the story; that one is the worksheet.

Capability judgements reflect documentation publicly available on 2026-08-24. Anything shipped after that date is outside this article's scope. Project figures come from the repository itself — git history, file counts, and the delivery notes written at the time.