Claude Code 2.1.282 ignores telemetry set by project files

Claude Code 2.1.282, released September 24, stops a repository’s own settings files from switching on OpenTelemetry export, choosing where the data goes or turning on content capture. Several other entries in this long release fix managed settings and permission rules that did not apply the way they were set.
The release notes on GitHub describe the ignored variables as those that “turn on export, set its endpoint, or capture content”, for example CLAUDE_CODE_ENABLE_TELEMETRY and OTEL_LOG_*. Anthropic’s observability docs explain what those variables control. OpenTelemetry instrumentation is built into the CLI. It records spans around each model request and tool execution, emits metrics for token and cost counters, and writes structured log events for prompts and tool results. None of it runs until CLAUDE_CODE_ENABLE_TELEMETRY=1 is set and at least one exporter is chosen. Each of the three signals (metrics, logs and traces) has its own exporter variable.
Claude Code now ignores those variables when they come from project and local settings. A startup notice and new entries in /status and claude doctor list the telemetry variables in a project’s settings files that were ignored or that turned telemetry off. For production deployments, the docs already recommend setting telemetry variables in the process environment.
Project files lose ground
Several other changes stop project-level files from overriding an admin’s choices. sandbox.excludedCommands now ignores project and local entries in two cases: when managed settings or --settings set allowUnsandboxedCommands: false, and when managed settings set allowManagedDomainsOnly: true. Under allowManagedPermissionRulesOnly, skills, commands and skills-directory plugin manifests from the repository, the user or --add-dir could still pre-approve their own tools through allowed-tools. That is now fixed. On Windows and WSL, an admin policy that is present but invalid or unreadable (HKLM or managed-settings.json) now keeps the user-writable HKCU and WSL /etc/claude-code settings from applying.
Some of the managed-settings fixes cover locks that admins had set but that never took effect. A mistyped value for a boolean lock key such as disableClaudeAiConnectors or allowManagedPermissionRulesOnly used to be ignored, which left the lock off. The lock now applies, and startup names the key. A single invalid nested value used to make Claude Code ignore an entire permissions, autoMode, worktree or attribution block. The rest of the block now still applies. Bash permission rules with a :* in the middle of the pattern were skipped when they came from settings files but honored when passed through --allowedTools. They now work from every source, and a startup warning explains how they match. That fix adds to a run of Bash permission patches from the summer.
Where did the reasoning go?
The second group of fixes concerns Claude’s extended thinking in session history. Three entries fix cases where earlier reasoning was lost:
--continueand--resumere-sent earlier messages in a changed form, which could make the API drop Claude’s earlier reasoning (this release fixes “more cases” of it);- using
/model,/rename,/artifactsor another immediate slash command while Claude was working dropped earlier thinking; - relaunching with a
--toolslist that left out a built-in tool offered earlier in the conversation did the same.
A fourth fix covers sessions that failed on every turn with an “Invalid data in redacted_thinking block” API error. Claude Code now drops the conversation’s thinking blocks and retries once. Another ends a 400 error on every request in conversations whose history holds web search results the API cannot decrypt, for example results from a turn answered through a third-party gateway. If compaction fails because the summarization request was refused, it now retries on a fallback model. Very large sessions, including ones that were never compacted, resume faster.
Auto mode has a new default too. On a direct Anthropic API connection with telemetry off, it now uses the server-side classifier. CLAUDE_CODE_AUTO_MODE_SERVER=0 opts out.
New settings
maxProseWidthcaps the width of Claude’s prose in wide terminals. Tables and code blocks keep the full width.allowClaudeInChromeWithManagedMcpis a managed setting that letsclaude --chromerun alongside an exclusivemanaged-mcp.json. The error shown when Chrome is blocked now names it.store.readiness_grace_secondskeeps the Claude apps gateway’s/readyzreporting ready through a short Postgres outage, such as a database failover.
Most of the remaining entries fix vim mode, the renderer, plugin uninstall, the VS Code panel, cloud sessions and the Slack integration. Among the login fixes, requests no longer fail for up to a minute with “another Claude Code process is refreshing it” after that other process was closed or killed mid-refresh.
Skill(anthropic-skills:*) and Skill(claude-ai:*) allow rules now cover only skills synced from claude.ai. Skill folders, command files and workflow commands in those two namespaces no longer load. A plugin with one of those names still loads, but it yields name ties to synced skills. MCP servers configured under either name keep their tools but list no skills or prompts. To get those back, rename the server in your MCP configuration.
Up next
Two Claude Code sessions ate 32% of a team’s bill
4% of Claude Code sessions ran up 65% of a ten-person team’s spend over 30 days. Two of them, kept open and resumed daily for over a week, took 32% of the bill on their own.
Related stories
- Claude Code 2.1.281 adds Bedrock guardrails to its gateway
- Claude Code 2.1.283 keeps new models out until admins say so
- Claude Code 2.1.317: email check, SDK hook block, cost API
- Claude Code 2.1.314 adds write fence, IdP groups, compaction
- Claude Code 2.1.311 can drop its last rm -rf guard
- Claude Code 2.1.309 closes sandbox and permission holes
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.

