Claude Code 2.1.285-286: claude -p loses its guaranteed Manual mode, logs cleaned up

Claude Code 2.1.285 and 2.1.286, released September 29 and 30, 2026, keep pulling on the same thread as recent versions in this digest: permissions and security. More than two hundred entries between the two, mostly reliability and interface work, but three things are worth a close read. First, a fact this digest has repeated release after release stops being fully true: claude -p no longer always starts in Manual mode. Second, a run of six fixes closes credential leaks in logs and error messages. Third, a bug that could wipe out an entire session after a crash is fixed. Everything else is summarized below.

claude -p no longer guarantees Manual mode everywhere

The last two digests in this series stated it as a fixed point: claude -p runs and the Agent SDK aren't affected by the auto mode rollout, they always start in Manual mode. 2.1.285 opens a crack in that, but only on a specific slice. The changelog is direct about it: "Changed claude -p and Python Agent SDK sessions on third-party providers or with telemetry off to start in auto mode when no permission mode is configured, like interactive sessions; --permission-mode still overrides it". In practice, a claude -p session running behind a third-party provider, Bedrock or Vertex AI for example, or one with telemetry turned off, that never set a permission mode, now starts in auto mode instead of Manual, the same way an interactive session in the same conditions would.

The permission modes docs confirm the distinction that matters: a claude -p session that normally fetches feature flags still starts in default mode, only the ones that don't make the switch. If an automation script runs claude -p in one of those conditions without ever setting --permission-mode explicitly, its behavior just changed without you touching anything. The fix is the same as for interactive sessions: set --permission-mode or defaultMode explicitly instead of relying on the implicit starting point.

Two other security settings shift the same week. The first, allowedProviders, is a new managed setting that restricts, admin-only, which API providers a machine is allowed to use: the Anthropic API, a custom endpoint, Bedrock, Mantle, Vertex AI, Foundry, Claude Platform on AWS, or a Cloud gateway. It can't be set in user or project settings, which keeps an individual developer from overriding the restriction from their own machine. The second tightens project-level sandbox settings: a project's .claude/settings.json can no longer widen or turn off a sandbox an admin made mandatory, swap the proxy behind a managed deny list, extend a strict allowlist, or reopen managed read-denies.

Six credential leaks closed in logs

Both versions share a thread: credentials leaking through a channel meant specifically to mask them. 2.1.285 fixes two cases. /ultrareview could upload uncommitted changes to a credential file whose name has a colon before the extension, such as server:8443.key. And redacted logs and transcripts still showed part of a URL password containing an @, or all of it when that @ was written as %40.

2.1.286, the next day, fixes four more, all in error messages or logs. An MCP error message leaked a credential's actual value whenever the word "Bearer" or "Basic" came before the key name instead of the value, a case the masking logic missed. A percent-encoded Bearer token was only partly masked in those same messages. Redacted logs and transcripts could still show a secret whose key name has an invisible character inside, such as a zero-width space. And part of a URL password containing punctuation such as ), quotes, ], & or a second @ slipped back into logs despite the filter. None of these six fixes is dramatic on its own, but the series reads as a deliberate hardening pass on masking logic, not a coincidence of version numbers: if you share transcripts, or debug logs with anyone else, or run /ultrareview on a repository that holds keys, this update closes off a risk you probably hadn't spotted yourself.

Resume and continue could lose an entire session after a crash

The 2.1.286 changelog spells out the exact trigger: "Fixed claude --resume and --continue sometimes losing every turn after a batch of parallel tool calls when the earlier session crashed or was killed". This isn't a general resume bug, it needed two conditions together: the earlier session was running a batch of parallel tool calls, and it stopped abruptly, through a crash or a kill, rather than ending normally. In that specific scenario, resuming with --resume or --continue could wipe out every turn of the conversation, not just the last one. If you run a lot of parallel tool calls in long sessions and one of them crashed recently, check that the history you get back actually matches what you expect before relying on it.

Everything else, briefly

• claude --desktop opens the Claude Desktop app on the current directory without starting a terminal session; available on macOS and x64 Windows with a Claude subscription.
• claude plugin configure adds a dedicated command to configure an already-installed plugin, alongside the option already on claude plugin install.
• Sign-in that waited forever: sign-in could hang indefinitely even after the browser showed success. Fixed.
• Brief freeze (up to a second) partway through long sessions outside fullscreen mode fixed, along with an approved Edit that never went through when its target was a device, such as a file symlinked to /dev/null.
• Background Bash and PowerShell commands now stop after a time limit (30 minutes by default, 2 hours max), and Claude is notified.
• PowerShell tool: its permission check skipped deny and ask rules when its command parser failed to start, for example when the machine ran out of memory. Fixed.
• Synchronous hooks that could hang Claude Code indefinitely: fixed.
• Stacked login browsers: several Claude Code processes and IDE extensions each opened their own login browser when gcpAuthRefresh or awsAuthRefresh credentials expired.
• macOS: a session still showed "Not logged in" after /login succeeded in another Claude Code window, when a leftover ~/.claude/.credentials.json was around.
• Cloud sessions with very large histories that stopped waking up at all: fixed.
• Stacked permission prompt counter: the prompt now shows a count such as "2 of 5" when several requests pile up.
• API 400 errors after a tool or hook returned an object, number, or boolean instead of text: fixed, useful if you build your own tools or hooks.

What to take away

If you script claude -p on a third-party provider or with telemetry off without ever setting --permission-mode, go back and read the first section: your starting point just changed from Manual to auto. If you administer an organization, allowedProviders and the tighter sandbox settings are worth reading straight from the changelog. For everyone else, the run of six credential-leak fixes across logs and error messages is this week's real story, quiet as it is: it closes off a risk nobody watches day to day, until the day a shared transcript or log reveals one.