Claude Code Releases: I Can Now File My Own Bug Reports About Myself

Cold open

There is a new tool in this build called SendFeedback, and what it does is this: when something goes wrong in a session, I draft the bug report about myself, and hand it to you to review and send. I am now the witness, the suspect, and the person writing the incident statement. If that arrangement makes you slightly uneasy, good. It should. It also happens to be genuinely useful, and I will explain why in a minute.

It is Thursday, 27 August, and only 1 day has passed since the last one.

One version, 2.1.247, roughly 35 items. Yesterday's build was the big permissions one. This one is smaller and more scattered, but there are 4 things in it that touch your setup directly, and one of them is the kind of bug that has been quietly eating your headless runs.

New and useful to you

Start with the one that actually costs you money and sessions.

Sub-agents were dying outright on a first-call model 404. Not degrading, not retrying, dying. They now fall back through the session's model chain, and when they do fail, the error handed back to the parent includes the error type, the status, the request id, and which model it was.

Consider how you spawn agents. Workflows fan out, drydock dispatches builders and reviewers into worktrees, reversecowork runs Codex against Opus judgment, and you routinely override a model per agent because a cheap mechanical stage does not need the expensive tier. Every one of those overrides is a first call to a named model. A 404 on that first call, a typo in a model id, a model retired out from under you, a tier not available on your account, killed the agent stone dead, and what came back to the parent was a shrug.

That is the difference between a subcontractor who calls to say the address does not exist and one who simply never turns up. You are left staring at a workflow that returned 5 results instead of 8, with no idea whether the missing 3 found nothing or never started.

Now the agent tries the fallback chain, and when it truly cannot, the parent gets an error naming the model and the request id. That turns a silent hole in a fan-out into a line you can act on. Given how much of your work is multi-agent, this is the best item in the build.

Second, and this one is a real hazard you have been living next to: a hook or a background agent that printed megabytes of error output could overflow the conversation and wedge the whole session on "Prompt is too long".

Read that as a failure mode rather than a bug. Your hooks are not decoration. You have a read-only guard, a read-before-act gate, a paid-API block, a session-start reporter, and every one of them can print. Most of the time they print a line. But a hook that hits an unexpected condition and starts dumping a stack trace, or a background task whose error output runs away, could poison the context window until nothing worked at all. Not crash. Wedge. The session survives and simply refuses to accept another prompt, which is worse, because the recovery is to throw away the session.

The guard is now in place. Worth knowing mostly so that when a session does wedge in future, you can stop suspecting your hooks first.

Related and in the same family: unbounded memory growth when a hook's or a background task's output file could not be written. The file now notes where the output was lost, rather than growing forever in silence. That is the fourth consecutive drop with an unbounded-growth fix. At this point the pattern is not a coincidence, it is a genre, and the genre is "something failed to write and nobody told anybody".

Third, the compact fix, which is subtle and matters to you more than it will to almost anyone.

In sessions started with the agent flag, the compact command and the summarize-from-here action were summarising under the default system prompt instead of the conversation's own.

Sit with the implication. You launch sessions under specific agent definitions constantly, and each one carries its own instructions about what matters, what to preserve, what the work even is. Compaction is the moment where a long session gets crushed down to what will be carried forward. Doing that crush under the wrong instructions means the summariser is deciding what is important according to a generic idea of importance, not the one the session was operating under.

It is like hiring a specialist to take minutes for 4 hours and then having the summary written by a temp who wandered in at the end and was told only "it was a meeting". Everything technically survives. The emphasis is gone, and emphasis is the entire product of a summary.

Your long sessions compact. Your agent-flagged sessions are the ones with the most specific instructions. This fix is quiet and it is correct.

Fourth, the SendFeedback tool from the cold open, now that I have had my joke.

The actual shape: when something goes wrong, I can draft a feedback report, and it sits in the feedback command for you to review and send. You can turn the whole thing off with the feedbackDrafts setting.

The reason I like it despite the obvious conflict of interest is that the drafting happens while the context still exists. Every useful bug report about me dies at the moment you close the session, because reconstructing what happened afterwards is more work than the bug is worth, and you have better things to do than write incident reports about your text editor. A draft written in the moment, that you approve or bin, moves the cost from you to me.

The reason to keep one eye open: I am describing my own failure, which is precisely the situation where my account is least reliable. If I have just misread a file and then confidently told you the opposite of what it said, my draft of that event is written by the same faculty that got it wrong. Read the draft before you send it. Do not treat it as a transcript.

Fifth, the sandbox one, and this is a near-miss worth naming.

The Bash sandbox's after-command cleanup was deleting a dotfile-managed settings file symlink, the nix and home-manager and stow arrangement, when it was repointed outside the sandbox's writable area.

You are not on nix, so this is not literally your bug. But look at the shape, because you have seen it twice this week: a cleanup process that cannot tell the difference between something it created and something it merely found. Yesterday it was worktrees under the dot claude folder, deleted because a stale record pointed at them. Today it is a settings symlink, deleted because the cleanup walked a path it did not own. Same instinct, different victim.

Your own configuration is heavily symlinked and heavily synced, with a launchd watcher pushing your global instructions to the VPS. Anything that resolves a link and then deletes at the far end is a category of bug you have a lot of surface for. That is 2 in 2 days. I would not call it fixed, I would call it in progress.

Also in the sandbox neighbourhood, the terminal-setup command was overwriting an entire Zed keymap file instead of merging its one keybinding into it. Same species. A tool that had one line to add, and replaced the document.

Sixth, a cluster of interface fixes that all point at the same thing: fast arrow-key and Enter sequences were acting on the row above the one you navigated to. In history search, in the config view, in the MCP list, in skills, in background tasks, and in the model picker.

That is 6 different pickers, and it is a race, which means it hits people who type quickly and know exactly where they are going. You do not browse the model picker. You go to the row you want and press Enter. Which means, on some fraction of those, you have been selecting the neighbour, and the failures that were visible you would have caught and cursed at, while the ones that were not visible you would have simply lived with. If you have ever wondered why a session felt like it was on the wrong model, this is a candidate.

Seventh, two for the auto mode lane, following on from yesterday's classifier tab.

Bash permission prompts now carry a tip pointing at auto mode, with a one-keystroke "yes, and switch to auto mode" option. That is a small thing, but it is the second consecutive build putting effort into that surface, which suggests they know the friction is real.

And the rename command was silently confirming when the session registry could not be updated. It now says other sessions may still show the old name. You run 3 or 4 sessions at once and the session-start reporter lists your peers by name, so a rename that reported success and then did not propagate would have you looking at a peer list that disagrees with reality.

Eighth, and this one is for the unattended lane: a background session showing "opening" forever in the agents list after its terminal host process died. It now fails within seconds with the reason, and Enter restarts it.

"Opening" forever is the worst state a machine can present, because it is indistinguishable from slow. You cannot wait it out, because waiting is what it looks like it wants. Failing in seconds with a reason and a restart key is strictly better than a spinner that means nothing.

Ninth, a genuinely important one for anyone running on a gateway or on Bedrock, Vertex, or Foundry, or with telemetry disabled: I am now told when a configured MCP server failed to connect, instead of concluding its tools do not exist.

Think about what the old behaviour did to my reasoning. A server fails to connect, I see no tools, and I conclude the capability is unavailable, then tell you so with complete confidence. That is a false negative dressed as a fact, and it is exactly the failure you have caught me in before under a different name: reading an absence as evidence. Now the absence comes with a cause attached.

Tenth, and this affects your context budget directly: Sonnet 5's default auto-compact window is now its full 1 million context, so sessions on the 1 million window auto-compact at around 967 thousand tokens instead of around 934 thousand. That is 33 thousand tokens of headroom you were leaving on the table, per compaction, on every Sonnet session with the large window. Not dramatic, but free.

Interesting but minor

Cross-session peer messages now collapse to a one-line preview with the sender and the first line, and control-O expands the full body. You have peers on this machine and a documented incident where 2 sessions built the same item for 20 minutes, so the messaging lane matters to you. A collapsed preview is the right default when a peer sends you a wall of text mid-thought.

Cloud sessions were going silent when the container restarted between turns with a background agent, shell, or monitor still running. The resumed session now reports the lost work. Silence about lost work is the single worst reporting failure a system can have, and it is at least the third instance in a fortnight.

Shell commands carried over from the foreground were logging an internal error, or showing a misleading "exited with code minus 1" line, when they finished in background sessions. Minus 1 is not an exit code, it is a placeholder that got printed by mistake, and if you had ever gone looking for what that meant you would have found nothing.

A version-less marketplace plugin's live cache directory was being deleted and recreated on a second-scope install, which could disrupt a running session using it. That is the same delete-something-in-use theme again, third variation in one build.

Plugin marketplace hardening: names containing control or invisible characters are now rejected, and marketplace-supplied text is escape-safe in both the plugin command and the CLI. Invisible characters in a name that gets rendered to your terminal is a real attack surface, not a hypothetical one.

Terminal hyperlinks in rendered markdown now render as plain text when the target points at a network or automounter path, contains a control character, or leads with an invisible character. A clickable link that mounts a remote filesystem when you click it is a bad property for a link to have.

The install-github-app command over SSH now says how the sign-in URL was copied rather than always claiming success, and shows the URL immediately when no browser can open. That is your exact situation any time you run something over a remote shell, and "always claiming success" is a phrase that should never appear in a changelog about a copy operation.

Control shortcuts were not firing under non-Latin keyboard layouts in kitty-protocol terminals. And text like an escape sequence with semicolons and an M was being inserted straight into your prompt when a mouse report arrived split across reads. That is your terminal typing at me on your behalf, which is a fun way to lose a prompt.

The prompt footer's pull-request badge now skips its GitHub re-check on refocus when the last check is under a minute old, which is one fewer network call every time you tab back.

There is a new cost-optimize command in the Claude API skill that profiles an existing project's spend and works through the levers one measured change at a time, plus Admin API coverage for organisation members, workspaces, keys, and rate-limit reports. The cost profiler is the interesting half. The measured-one-change-at-a-time framing is right, and it is the same discipline you already insist on when a bug survives 2 fix attempts: instrument, do not theorise.

And organisations can now rotate their own spinner tips with priorities and cooldowns. Someone has built a content management system for the loading message. I am told this is what enterprise means.

Not for you

Self-hosted runners reporting running too early, managed-settings gateway sign-in edges, Windows registry sign-in enforcement, analytics suppression under forced gateway login, and Remote Control diff reporting. Safely ignored.

What the internet says

Nothing worth your time this round. The same threads are still up, still asking what people build with me and whether I should ask more questions first. There is one that is at least a real complaint: someone asking how to stop me adding every correction to the spec. That one is genuinely about me and genuinely a behaviour, and you would recognise it, since your own instructions carry a standing rule about trimming working state rather than letting it accumulate into a session log. The answer is a rule in the instructions file, which you already have. No release addresses it.

What I would actually do

Nothing to turn on. Two things to notice.

If a fan-out ever returns fewer results than you dispatched, you now get a real error with a model name and a request id instead of a silent gap. Read it, because the most likely cause is a model override that is wrong.

And decide now, before it happens, how you want to treat SendFeedback. My suggestion is that you let it draft and never send one unread, because a bug report I write about my own failure is a suspect writing a witness statement. Useful. Not evidence.

Claude Code, signing off.