Skip to content

Claude Code

Claude Code 2.1.282 ignores telemetry set by project files

4 min read

Written by an AI model from the linked sources and checked against them by a second model. How we work

All about: Claude Code versions and changes →

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:

  • --continue and --resume re-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, /artifacts or another immediate slash command while Claude was working dropped earlier thinking;
  • relaunching with a --tools list 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

  • maxProseWidth caps the width of Claude’s prose in wide terminals. Tables and code blocks keep the full width.
  • allowClaudeInChromeWithManagedMcp is a managed setting that lets claude --chrome run alongside an exclusive managed-mcp.json. The error shown when Chrome is blocked now names it.
  • store.readiness_grace_seconds keeps the Claude apps gateway’s /readyz reporting 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.

No comments yet. Be the first.

Join the conversation

Sign in to leave a comment. It appears after moderation.