Claude Code 2.1.269: Three Operator Changes Hidden Inside a 60-Fix Release

Claude Code 2.1.269 landed this morning with over sixty individual changes. Most of the changelog reads like terminal polish — cursor rendering in obscure terminal emulators, stray characters over slow SSH connections, the kind of fixes that matter a lot to the person who hit them and zero to everyone else. Buried inside, though, are three changes that operators running Claude Code at team or enterprise scale should read before the next session starts.

The gateway discovery timeout was hardcoded at three seconds

When Claude Code starts a session and a custom LLM gateway is configured, it probes /v1/models to discover what models are available before the first request goes out. That probe had a hardcoded three-second timeout with no way to adjust it.

Three seconds is fine for a gateway running on the same local network. It breaks in two common production configurations: a gateway with a cold-start startup path (Lambda, Cloud Run, any function-as-a-service backend), and a gateway sitting behind a corporate proxy with inspection overhead. The session would fail model discovery, fall back to defaults, and silently route differently than configured — or fail the session entirely.

2.1.269 adds CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS. Set it to any value in milliseconds to override the three-second default:

export CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS=10000  # 10 seconds

If you route Claude Code through an enterprise gateway with non-trivial cold-start latency, this env var belongs in your deployment config alongside ANTHROPIC_BASE_URL. The previous workaround was to pre-warm the gateway endpoint before sessions started; this removes that requirement.

The three-second default is not inherently wrong for locally-hosted gateways, so there is no reason to raise this value unless you observe discovery failures.

Concurrent workflow agents now have an operator-settable cap

The Workflow tool lets Claude Code fan out work across parallel sub-agents. Before 2.1.269, the per-run concurrent agent limit was set internally by Claude Code with no operator control. When a task decomposed into many parallel branches, the effective concurrency was up to the model's own judgment.

2.1.269 adds CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS. The parameter accepts an integer from 1 to 256:

export CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS=8

This is meaningful in two directions. For teams concerned about inference cost — parallel agents burning through quota simultaneously — this cap limits burst concurrency without restricting what the Workflow tool can do overall; work that exceeds the cap queues rather than errors. For teams that want more aggressive parallelism than Claude Code's internal defaults allow, values above the default unlock that.

The value to actually set depends on your provider's rate limits and your team's cost envelope. A team running Claude Code against a gateway with tiered quotas should treat this the same way they treat connection-pool sizing: set it once, monitor token spend on the first few parallel workflows, then tune.

A deny rule that started with ! was leaking beyond its config source

This one is the highest-severity change in the release, and the bug description in the changelog is easy to underread: "Fixed a deny or ask permission rule starting with ! applying beyond the settings source that wrote it; such a rule now applies only within its own source, and a bare ! negation is ignored."

Claude Code applies permission rules from multiple sources in a hierarchy: organization managed settings, project-level settings, user settings, local .claude/settings.json. A deny rule that starts with ! is a negation — it excludes a path from a broader allow. The bug was that those negation rules were being treated as global, applying to every source rather than just the one that wrote the rule. A negation rule in, say, a project .claude/settings.json file would silently extend its effect into organization-level allow grants.

In practical terms: if you wrote a project-level ! rule to carve out an exception in a project-scoped allow, that carve-out was also restricting org-level allows that the org admin expected to be in full effect. Depending on what those allows covered, a team could have been running with tighter restrictions than intended — or, in a different configuration, looser ones.

The fix is surgical: each ! rule now scopes only to the source that wrote it. Existing configurations that relied on the old (incorrect) cross-source behavior will behave differently after upgrading. Before deploying 2.1.269 across a fleet, review your permission rule configurations at each source level and verify the intended scope.

This also applies to Bedrock and Vertex deployments that use managed settings — the same permission pipeline runs regardless of which provider receives the inference request.

What the prompt cache fixes mean for long-running agents

Two cache fixes in 2.1.269 address scenarios that mostly affect long-running or multi-turn agent sessions:

The first fixes partial cache invalidation after an output-token-limit cutoff. When Claude Code hit the output token limit mid-response and auto-resumed, the prompt cache was partially invalidated on the following turn. Teams running agents with large contexts that routinely hit the output limit were paying uncached input prices on the resume turn — a cost that should have been cached.

The second fixes a session-interruption scenario: resuming a session after interrupting Claude mid-thought could change how earlier context was re-sent, hurting cache reuse on the resumed turn. Both fixes compound when they overlap — a session that was frequently interrupted and frequently hitting output limits was losing cache reuse on both.

Neither fix requires configuration changes. They take effect on upgrade.

What TheRouter users should check

If you route Claude Code sessions through a custom endpoint, add CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS to your deployment alongside ANTHROPIC_BASE_URL. Start with a value that gives your gateway a comfortable margin above its p95 startup latency.

If you use the Workflow tool in fan-out workloads, set CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS to match your provider's rate limits. Burst concurrency that exceeds quota produces retryable errors, but those retries count against your rate-limit window and add latency to the whole workflow.

Review your permission rule configurations before deploying 2.1.269 to existing fleet members, particularly any rules that use ! negation at project or local scope. The change is correct, but it can shift effective behavior for configurations that were depending on the old cross-source propagation.

Previous coverage on related Claude Code operator changes: Claude Code 2.1.268 gateway fix, Claude Code 2.1.266 gateway regression.