claude-code - 💡(How to fix) Fix [DOCS] Document server-side system prompt experiments and their opt-out controls

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

A change to the conversation layer leaves the system prompt and project context cached. A change to the system prompt invalidates everything, because all later content now sits behind a different prefix.

RAW_BUFFERClick to expand / collapse

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/env-vars https://code.claude.com/docs/en/data-usage https://code.claude.com/docs/en/security https://code.claude.com/docs/en/prompt-caching https://code.claude.com/docs/en/debug-your-config

Section/Topic

Server-side configuration, feature flags, and experiments that can affect Claude Code's built-in system prompt

Current Documentation

The environment variable reference currently documents CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT as follows:

Set to 1 to use a shorter system prompt and abbreviated tool descriptions on any model. Set to 0, false, no, or off to opt out even on models where the experiment or server configuration would otherwise enable it. The full tool set, hooks, MCP servers, and CLAUDE.md discovery remain enabled

The same page documents DISABLE_GROWTHBOOK as follows:

Set to 1 to disable GrowthBook feature-flag fetching and use code defaults for every flag. Telemetry event logging stays on unless DISABLE_TELEMETRY is also set

It also documents DISABLE_TELEMETRY as follows:

Set to 1 to opt out of telemetry. Telemetry events do not include user data like code, file paths, or bash commands. Also disables feature-flag fetching with the same effect as DISABLE_GROWTHBOOK, so some flagged features may be unavailable

The prompt-caching page currently says:

Each time you send a message in Claude Code, it makes a new API request. The model doesn't remember anything between requests, so Claude Code re-sends the full context: the system prompt, your project context, every prior message and tool result, and your new message.

It also says:

A change to the conversation layer leaves the system prompt and project context cached. A change to the system prompt invalidates everything, because all later content now sits behind a different prefix.

The debug-your-config page currently says:

The /context command shows everything occupying the context window for the current session, broken down by category: system prompt, memory files, skills, MCP tools, and conversation messages.

What's Wrong or Missing?

The docs now imply that server configuration or experiments can affect the system prompt, but they do not clearly document the general behavior.

The only explicit example I found is CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT. That page acknowledges that an experiment or server configuration may enable a different system prompt shape, and it documents a per-feature opt-out for that specific shorter-prompt behavior. Separately, DISABLE_GROWTHBOOK and DISABLE_TELEMETRY document feature-flag fetching and default values.

What remains unclear is the broader contract:

  • Whether Claude Code may use server-side configuration or feature flags to add, remove, or alter built-in system prompt sections.
  • Which opt-out variables cover system-prompt experiments specifically.
  • Whether CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is intended to opt out of all system-prompt experiments, only GrowthBook-backed experiments through DISABLE_TELEMETRY, or only the nonessential traffic classes listed on the env-vars page.
  • How a user can inspect the effective system prompt when a server-side experiment is active.
  • Whether /context shows enough detail to audit server-injected system-prompt sections, or whether raw API-body logging is required.

This is separate from the existing open issue about DISABLE_TELEMETRY and experiment-gate side effects. That issue covers telemetry and remote gate fetching in general. This issue is specifically about documentation for server-side changes to the Claude Code system prompt, which is a higher-impact behavior because the system prompt is the instruction layer for an agent with tools.

Suggested Improvement

Add a short section to env-vars, data-usage, or security that explicitly documents the system-prompt experiment contract.

Suggested coverage:

  • State that Claude Code may use server-side configuration or feature flags to evaluate changes to built-in system prompt sections before broad rollout, if that is intended product behavior.
  • State which controls opt out of system-prompt experiments:
  • DISABLE_GROWTHBOOK=1
  • DISABLE_TELEMETRY=1, if it disables all feature-flag fetching
  • CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, if it is intended to cover this path
  • feature-specific controls such as CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT=0
  • Explain that system-prompt changes can alter prompt-cache behavior because the system prompt is part of the request prefix.
  • Cross-link to /context and raw API-body logging so users know how to inspect the effective context when debugging.
  • Clarify whether /context is sufficient for auditing server-supplied built-in system-prompt sections, or whether OTEL_LOG_RAW_API_BODIES=file:<dir> is the only complete mechanism.

Possible wording:

Claude Code may use server-side configuration and feature flags to evaluate changes to built-in system prompt sections before broad rollout. These changes can affect the system prompt sent with Claude Code requests. To opt out of feature-flag-driven behavior, set DISABLE_GROWTHBOOK=1; setting DISABLE_TELEMETRY=1 has the same effect for feature-flag fetching. If you need to inspect what loaded into context, use /context; for complete request-level debugging, use OTEL_LOG_RAW_API_BODIES=file:<dir> with care because raw request bodies can contain sensitive conversation content.

Impact

Medium - Makes feature difficult to understand

Additional Context

This gap became visible in the public discussion on:

In that issue, a commenter with an Anthropic company profile wrote:

We sometimes run experiments on changes to our system prompt so that we can evaluate how a change impacts quality before fully rolling it out to everyone. This is primarily so that we can catch and prevent quality regressions. You can opt out of any and all of these experiments using CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 and DISABLE_GROWTHBOOK=1.

Related existing docs issue:

This draft is intentionally narrower: it asks for system-prompt-specific disclosure, opt-out semantics, and inspection/audit guidance.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING