--- title: "Claude Code 2.1.199 Adds Stacked Slash-Skill Invocations, Fixes Subagent Error Reporting, the Background-Agent Daemon Crash Loop on Linux, and the Streaming-Response Discard Bug" description: "Anthropic released Claude Code [v2.1.199](https://github.com/anthropics/claude-code/releases/tag/v2.1.199) on 2026-07-02, one day after the v2.1.198 feature release (Chrome GA, background-agent auto-PR, /dataviz, Gateway on AWS) and two days after v2.1.197 made Sonnet 5 the default model. v2.1.199 is a bug-fix release with 24 entries: one new feature (stacked slash-skill invocations load up to 5 leading skills in one prompt), and a long list of reliability fixes for subagent error reporting, the background-agent daemon on Linux, streaming-response preservation on mid-stream API errors, SSL/TLS error handling behind corporate proxies, plan mode tool-call handling, and a per-env retry policy that no longer caps the user-tunable retry count at 15. Most of the items are in the background-agent / subagent area, which is consistent with the v2.1.197 + v2.1.198 direction of treating delegation as the product surface for Sonnet 5." date: 2026-07-03 image: "/images/heroes/2026-07-03--claude-code-2-1-199-stacked-skills-subagent-errors.png" author: lschvn tags: ["ai", "tooling"] tldr: - "[Claude Code v2.1.199](https://github.com/anthropics/claude-code/releases/tag/v2.1.199) (released 2026-07-02, 23:35:18 UTC) ships 24 changelog entries: one new feature (stacked slash-skill invocations load up to 5 leading skills in one prompt) and 23 bug fixes. The fix list is dominated by background-agent and subagent reliability: subagents cut off by a rate limit or server error used to silently fail and now return their partial work; subagents that hit an API error used to report success and now report the error; the Linux background-agent daemon used to kill itself and every running agent every ~50 seconds after an unclean shutdown left a corrupted worker record; and a regression in v2.1.196 made background agents fail to cold-start over SSH on macOS with `Could not switch to audit session`." - "Three of the fixes target silent data loss: streaming responses that the API cut off mid-stream (overloaded, server error) used to be discarded with the partial output, and are now kept with an `incomplete-response` notice; SSL/TLS errors behind corporate proxies (TLS-inspecting proxies, missing `NODE_EXTRA_CA_CERTS`, expired certs) used to burn retries before showing actionable guidance and now fail immediately with the fix hint; and resetting a corrupted config file from the startup recovery dialog used to destroy it unrecoverably, and now backs it up first. The release also fixes a `/diff` panel that did not refresh on out-of-band commits, plan mode not auto-allowing read-only `browser_batch` calls, and a `SendMessage` misrouting bug when a re-spawned agent reused a previous agent's name." - "The release raises the default retry count for non-capacity transient errors to 300 and lifts the cap of 15 on `CLAUDE_CODE_MAX_RETRIES`, so transient 429s unrelated to the user's usage limit now retry automatically with backoff for subscribers instead of failing the turn. This is the third consecutive Claude Code release this week (after [v2.1.197 Sonnet 5 default](/articles/2026-07-01--claude-sonnet-5-default-model-claude-code-1m-context) and [v2.1.198 Chrome GA + background-agent auto-PR](/articles/2026-07-02--claude-code-2-1-198-chrome-ga-background-agents-auto-pr)); the day-after-day cadence suggests Anthropic is iterating the v2.1.19x line at the same speed the model itself is moving." faq: - question: "What changed in Claude Code 2.1.199?" answer: "Claude Code 2.1.199 (released 2026-07-02, 23:35:18 UTC) is a bug-fix release with 24 changelog entries. The single new feature is stacked slash-skill invocations: a prompt like `/skill-a /skill-b do XYZ` now loads the first 5 leading skills instead of just the first. The rest are fixes, dominated by background-agent and subagent reliability: subagents cut off by a rate limit or server error now return their partial work instead of silently failing, subagents that hit an API error now report the error to the parent, the Linux background-agent daemon crash-loop after a corrupted worker record is fixed, the v2.1.196 background-agent SSH-cold-start regression on macOS is fixed, and `claude stop` no longer races a background-agent respawn. The release also fixes the streaming-response discard bug, the SSL/TLS error handling behind corporate proxies, plan mode auto-allow for read-only browser tools, and the `SendMessage` misrouting bug. A retry-policy change raises the default non-capacity transient retry count to 300 and lifts the cap of 15 on `CLAUDE_CODE_MAX_RETRIES`." - question: "What are stacked slash-skill invocations in Claude Code 2.1.199?" answer: "In Claude Code 2.1.199, a prompt that starts with several slash-skill tokens now loads all of them, not just the first. A command like `/skill-a /skill-b do XYZ` loads both `skill-a` and `skill-b` before running the prompt. The release caps the leading-skill count at 5; a sixth and beyond are ignored. The feature is additive: existing single-skill invocations are unchanged, and a user that wants only one skill in scope can still write `/skill-a do XYZ` and get the same behavior as before. The change is the only new feature in an otherwise bug-fix release." - question: "What was the background-agent daemon crash loop on Linux?" answer: "Before v2.1.199, an unclean shutdown of the background-agent daemon on Linux could leave a corrupted worker record on disk. The daemon's recovery code would then try to read the record, fail, and exit; the supervisor would respawn the daemon, which would fail again on the same record. The result was a kill-and-respawn cycle roughly every 50 seconds that took down every running background agent. v2.1.199 fixes the recovery code so the corrupted record is detected and replaced with a fresh one instead of crashing the daemon. The crash loop is the kind of issue that surfaces in long-running CI and dashboarded worktree agents rather than in interactive single-session use, which is why the fix lands two releases after v2.1.198 made the auto-PR flow the default for background agents." - question: "What was the streaming-response discard bug?" answer: "When the Anthropic API emitted a mid-stream overloaded or server error after the model had already produced partial output, Claude Code 2.1.198 and earlier discarded the partial response along with the error, leaving the user with nothing. v2.1.199 keeps the partial output and appends an `incomplete-response` notice. The change matters for long generations (a Sonnet 5 1M-context run, for example) where a transient 529 or 503 late in the stream used to lose several seconds of work. The fix is paired with the new retry policy that raises the default non-capacity transient retry count to 300: the partial is kept when retries are exhausted, and a partial turn is no longer wasted on the first transient error." - question: "Why did subagents silently fail in earlier versions?" answer: "Three independent failure modes in v2.1.198 and earlier made subagent failures invisible to the parent agent. (1) A subagent cut off by a rate limit or server error returned nothing to the parent, so the parent treated the task as abandoned. (2) A subagent that hit an API error mid-task reported a successful result to the parent, so the parent used partial garbage as the answer. (3) `SendMessage` silently misrouted when a re-spawned agent reused a previous agent's name. v2.1.199 fixes all three: the partial work is returned with the error, the API error is reported as the error, and the `SendMessage` tool detects the name mismatch and asks the caller to retarget. Together the fixes turn a silent partial-failure mode into a visible, recoverable one." - question: "What changed in the Claude Code retry policy in 2.1.199?" answer: "v2.1.199 raises the default retry count for non-capacity transient errors (429s unrelated to the user's usage limit, 500-class server errors, 529 overloaded) from a small fixed value to 300, with backoff. The release also lifts the previous cap of 15 on the `CLAUDE_CODE_MAX_RETRIES` environment variable, so users and CI scripts can set a higher cap without it being silently clamped. The change is targeted: capacity-style errors (the user's own rate limit, the Pro/Max usage cap) are not affected, and subscribers get automatic retry while a session on a usage cap still surfaces the cap as before. The `CLAUDE_CODE_RETRY_WATCHDOG` env var, which bounds the total time spent retrying across a turn, is unchanged." - question: "Is Claude Code 2.1.199 safe to upgrade to today?" answer: "Yes. v2.1.199 is a bug-fix release on the same v2.1.19x line as v2.1.197 (Sonnet 5 default) and v2.1.198 (Chrome GA, background-agent auto-PR), and the changes are additive. The only behavior change worth flagging is the new stacked slash-skill feature, which loads up to 5 leading skills in a prompt and is a strict superset of the previous single-skill behavior. The retry-policy change is a default that can be reverted with the existing `CLAUDE_CODE_MAX_RETRIES` env var. The recommended transition is `claude update` (or the in-app update prompt), a quick check that any background-agent / CI workflow that previously saw silent partial failures is now seeing the partial returned, and a check that any enterprise TLS-inspecting proxy is configured with `NODE_EXTRA_CA_CERTS` (the new SSL error path is louder about the missing config)." --- [Claude Code v2.1.199](https://github.com/anthropics/claude-code/releases/tag/v2.1.199) shipped on 2026-07-02 at 23:35:18 UTC, one day after [v2.1.198](https://github.com/anthropics/claude-code/releases/tag/v2.1.198) (the Chrome GA + background-agent auto-PR + /dataviz + Gateway on AWS release) and two days after [v2.1.197](https://github.com/anthropics/claude-code/releases/tag/v2.1.197) made [Sonnet 5 the default model](/articles/2026-07-01--claude-sonnet-5-default-model-claude-code-1m-context). The release notes are unusually long for a one-day cycle: 24 changelog entries, one new feature and 23 bug fixes, with the fix list concentrated in the same area v2.1.198 expanded (background agents, subagents, the auto-PR workflow, plan mode) plus a long tail of smaller UX fixes. The pattern matches the previous two releases: Anthropic is iterating the v2.1.19x line at the same pace as the underlying model, and the product surface for Sonnet 5 is being hardened release-on-release. ## The one new feature: stacked slash-skill invocations The single new feature in v2.1.199 is a small but useful expansion of the slash-skill surface. In v2.1.198 and earlier, a prompt like `/skill-a /skill-b do XYZ` loaded only the first skill, `skill-a`; the second `/skill-b` was treated as part of the prompt text, not as another skill invocation. v2.1.199 changes the rule: the parser walks the leading tokens of the prompt and loads up to 5 slash-skills before falling through to the rest of the message. A command like `/plan /review /dataviz do XYZ` now loads `plan`, `review`, and `dataviz` as the active skill set, instead of loading only `plan` and silently dropping the rest. The 5-skill cap is a guardrail, not a feature ceiling: skills carry their own context and tool surface, and a 6th skill would be the kind of prompt shape that already warrants a custom subagent instead of an inline skill chain. The cap is generous for the common cases (2 to 3 skills to combine a planning step, a code-review step, and a visualization step) and conservative for the edge cases (an over-eager agent that would otherwise scope-creep into a half-dozen overlapping skill contexts). The change is additive: existing single-skill invocations are unchanged, and a user that wants only one skill in scope can still write `/skill-a do XYZ` and get the same behavior as before. ## Subagent error reporting and partial-work recovery The deepest cluster of fixes in v2.1.199 is in the subagent / background-agent surface, and three of them are about making failures visible to the parent agent. In v2.1.198 and earlier, three independent failure modes hid partial work from the orchestrator: 1. **Subagents cut off by a rate limit or server error silently failed.** A subagent that ran out of context, hit a 429, or got a 5xx from the API would return nothing to the parent. The parent had no way to tell the difference between an unfinished task and a task that had never been started, and the partial work the subagent had already done was lost. 2. **Subagents reported API errors as successful results.** A subagent that hit an API error mid-task (a usage-limit error, a 529 overloaded, a model error) would return a result envelope to the parent, with the error surfaced as text inside the result. The parent would treat the envelope as success and use the error text as the answer. 3. **`SendMessage` silently misrouted when a re-spawned agent reused a previous agent's name.** When an agent died and a new agent took its name in the agent panel, a follow-up `SendMessage` would sometimes hit the dead agent's record and route to a stale conversation. The parent had no error, just a missing reply. v2.1.199 fixes all three. Subagents cut off by a rate limit or server error now return their partial work to the parent, with the error attached. Subagents that hit an API error now report the error to the parent, with the partial work kept as a separate field on the result envelope. `SendMessage` detects the name mismatch and asks the caller to retarget, surfacing the routing problem as a tool error rather than a silent miss. The pattern is the same as the v2.1.198 fix for agent teams (a teammate that died on an API error now reports `failed` to the lead), and the two releases together turn the v2.1.196-era "subagents look like they succeeded but actually did not" failure mode into a visible, recoverable one. ## Background-agent daemon crash loop on Linux The most operationally painful fix in the release is the background-agent daemon crash loop on Linux. Before v2.1.199, an unclean shutdown of the daemon (a kill -9, a host OOM, a power loss, a crash inside a child process) could leave a corrupted worker record on disk in the daemon's state directory. The daemon's recovery code on the next start would try to read the record, fail on the corruption, log an error, and exit; the supervisor would respawn the daemon, which would fail on the same record; and the cycle would repeat every ~50 seconds. Every running background agent in the user's workspace would die with the daemon. The crash loop is the kind of issue that surfaces in long-running CI and dashboarded worktree agents rather than in interactive single-session use, which is why it lands two releases after v2.1.198 made the auto-PR flow the default for background agents. v2.1.199 fixes the recovery code so the corrupted record is detected and replaced with a fresh one instead of crashing the daemon; the supervisor respawn is now a recovery action, not a repeating failure. The release also fixes a related v2.1.196 regression: background agents that tried to cold-start over SSH on macOS were failing with `Could not switch to audit session`, which made the SSH-on-macOS launch path unusable for teams that run Claude Code on a remote Mac. The fix is a one-line change in the SSH launch wrapper that explicitly switches the audit session before the agent tries to bind to it. ## Streaming-response preservation on mid-stream API errors Two related fixes target the moment a model call is in flight and the API cuts it off. The first is the streaming-response discard bug: when the Anthropic API emitted a mid-stream overloaded (529) or server error (5xx) after the model had already produced partial output, Claude Code 2.1.198 and earlier discarded the partial response along with the error, leaving the user with nothing. v2.1.199 keeps the partial output and appends an `incomplete-response` notice. The change matters most for long generations: a Sonnet 5 1M-context run, a multi-file refactor with thousands of tool calls, a `/dataviz` chart with a long explanation, all of them can lose several seconds of work to a single late-stream 529 under v2.1.198. The fix is paired with the new retry policy (see below): a partial turn is no longer wasted on the first transient error, and the partial is kept when retries are exhausted. The second is the SSL/TLS error handling behind corporate proxies. In v2.1.198 and earlier, an SSL handshake failure caused by a TLS-inspecting proxy, a missing `NODE_EXTRA_CA_CERTS`, or an expired certificate would burn the full retry budget before showing any guidance. v2.1.199 changes the path: SSL errors fail immediately with a fix hint that names the most likely cause (`NODE_EXTRA_CA_CERTS` for a missing CA bundle, certificate check for an expired cert, proxy trust store for a corporate MITM). The change is a quality-of-error improvement, not a behavior change: the same error is now diagnosed in one turn instead of five, and the retry budget is preserved for transient errors that actually deserve retries. ## Plan mode, hook stderr, and the `claude agents` view The plan-mode fixes in v2.1.199 are smaller but cover two distinct paper cuts. First, plan mode was not prompting for state-changing browser tool calls; a session in plan mode that tried to call a state-changing browser action would silently auto-allow the call instead of asking the user. v2.1.199 keeps the existing auto-allow for read-only `browser_batch` calls (the safe, read-only path through the Chrome extension) and adds the missing prompt for state-changing browser tool calls. The split matches the v2.1.198 fix that auto-allowed read-only tool calls when a session starts in plan mode, and it closes the asymmetric treatment of the read-only and state-changing browser tools. Second, the `SessionStart`, `Setup`, and `SubagentStart` hooks were silently hiding stderr when they exited with code 2. A hook that failed with a missing dependency, a parse error, or a runtime exception would log to stderr, exit 2, and leave the user with a successful-looking hook result. v2.1.199 shows the stderr in the transcript when a hook exits non-zero, so a misbehaving hook is visible to the user instead of being a silent fail. The change matters for the same reason the v2.1.197 `MCP` trust fix mattered: a hook is a user-controlled script, and a silent failure of a user-controlled script is a debugging time-sink. The release also fixes a `claude agents` view bug: idle subagents used to vanish from the agent panel while other subagents were still working, leaving the user with a partial view of their running agents. v2.1.199 collapses surplus idle agents into an expandable summary row, so the user always sees the active agents and can expand the row to see the idle ones. The same view gets a fix where typing `/model` or `/fast` while viewing a subagent was silently opening the lead's model picker; v2.1.199 shows a notice explaining the command applies to the lead, and the same fix prevents the model picker from being opened in the wrong context. The `claude agents` session rows also get a cosmetic fix: pull-request links now show as bare `#N` without the redundant "PR" label. ## Retry policy, watchdog, and transient 429s The most user-visible behavior change in v2.1.199 is the retry policy. The release raises the default retry count for non-capacity transient errors (429s unrelated to the user's usage limit, 500-class server errors, 529 overloaded) from a small fixed value to 300, with backoff. The release also lifts the previous cap of 15 on the `CLAUDE_CODE_MAX_RETRIES` environment variable, so users and CI scripts can set a higher cap without it being silently clamped. The change is targeted: capacity-style errors (the user's own rate limit, the Pro/Max usage cap) are not affected, and subscribers get automatic retry while a session on a usage cap still surfaces the cap as before. The `CLAUDE_CODE_RETRY_WATCHDOG` env var, which bounds the total time spent retrying across a turn, is unchanged, so a runaway retry loop still gets caught by the watchdog. The fix is paired with the v2.1.198 network-drop retry (transient errors like `ECONNRESET` now retry with backoff instead of aborting the turn), and the two together turn the "transient network blip aborts a long generation" failure mode into "transient blip is retried, the partial is kept if retries are exhausted, the cap is still respected." For CI workflows that run Claude Code against a fleet of repos, the change is a strict improvement: a long generation that hits a 529 at minute 8 of a 10-minute run no longer needs to be re-run from scratch. ## Smaller fixes worth flagging The v2.1.199 release notes close a long tail of small fixes. Background job progress indicators no longer stall for minutes while the job runs long commands. Background sessions on memory-starved machines now indicate low memory and suggest freeing resources, instead of showing a generic error. Remote sessions no longer flap between `Working` and `Idle` in the agent view when a background agent completes. `claude stop` is no longer silently undone by a racing background-agent respawn; the respawn now honors the stop. Opening or resuming a session with no new messages no longer grows the transcript file. Backgrounding a session with `←` or `/background` no longer drops its `/color` from the agent view row. Resetting a corrupted config file from the startup recovery dialog no longer destroys the file unrecoverably; it now backs it up first. `claude --dangerously-skip-permissions daemon ` is no longer treated as a chat prompt; the subcommand is now run. Claude in Chrome no longer repeatedly opens the reconnect page when sessions run from different builds or config directories. ## Why this matters for Claude Code users v2.1.199 is the third consecutive Claude Code release this week, and the third consecutive release to harden the same surface: the background-agent and subagent workflow that [v2.1.198 made the default for code work in a worktree](/articles/2026-07-02--claude-code-2-1-198-chrome-ga-background-agents-auto-pr), on top of the Sonnet 5 default that [v2.1.197 introduced two days earlier](/articles/2026-07-01--claude-sonnet-5-default-model-claude-code-1m-context). The pattern is consistent: the model is settled, the auto-PR flow is settled, and the work is on the failure modes that the auto-PR flow surfaces in production. The background-agent daemon crash loop on Linux, the streaming-response discard bug, the silent subagent failures, the SSL error handling behind corporate proxies, and the plan-mode asymmetry are exactly the kind of issues that only show up when the workflow is running unattended in a CI pipeline or a long-lived dashboarded worktree, not in the interactive single-session use that dominated Claude Code's first year. For Claude Code users, the practical takeaway is a quieter `claude update` window on a Friday morning. The release is additive; existing single-session workflows are unchanged. The single new feature (stacked slash-skill invocations) is a strict superset of the previous behavior. The retry policy is a default that can be reverted with the existing `CLAUDE_CODE_MAX_RETRIES` env var. And the failure-mode fixes (subagent errors, streaming-response preservation, plan-mode asymmetry) are the kind of change a working Claude Code user notices only when they don't fire, which is the point.