[Bug] Custom output styles do not strip conciseness instructions — server-side feature flags bypass exclusion logic

Resolved 💬 7 comments Opened Mar 5, 2026 by idiolect-ai Closed May 10, 2026

Bug Description

Custom output styles are documented to strip conciseness instructions from the system prompt:

All output styles exclude instructions for efficient output (such as responding concisely). — Output Styles documentation

This does not work. The conciseness sections ("Output efficiency" and "Tone and style" variants) are injected via server-side feature flags through a separate code path from the one output styles strip. The feature flag injection bypasses the exclusion logic entirely.

This is not a v2.1.69 regression (as originally reported). Testing across v2.1.56, v2.1.66, and v2.1.68 confirms the same sections are present regardless of client version. Rolling back the CLI does not fix the issue because the flags are server-side.

Root Cause

Analysis of the compiled CC binary reveals that the conciseness sections are gated behind server-side feature flags and injected through a separate code path from the one that handles output style exclusion. The output style stripping logic never sees these sections because they're injected independently.

Additionally, the "Output efficiency" section has three intensity tiers that appear to be A/B tested:

  • Strict: "CRITICAL: Go straight to the point... Be extremely concise. Use the fewest words necessary."
  • Focused: "IMPORTANT: Go straight to the point... Be extra concise." (currently active for our account)
  • Polished: "Go straight to the point... Be concise." (lighter)

The "Tone and style" conciseness section also has a feature-flag-gated variant toggle between a short version ("Your responses should be short and concise") and a detailed version ("Your output to the user should be concise and polished...").

The feature flag code exists in the v2.1.56 binary, meaning it shipped well before v2.1.69 — only the server-side flag enablement changed. This explains why rolling back the CLI version has no effect.

How to Reproduce

  1. Create a custom output style with depth-oriented instructions
  2. Set "outputStyle": "my-style" in .claude/settings.json
  3. Start a session and ask Claude to report what conciseness-related instructions it sees

Expected: Per documentation, conciseness instructions should be absent from the system prompt when any output style is active.

Actual: The full "Output efficiency" section and "Tone and style" conciseness section are both present, creating contradictory instructions. Verified on v2.1.56, v2.1.66, and v2.1.68.

Impact

For any project using custom output styles for non-engineering work (creative writing, research, editorial analysis), the model receives contradictory instructions:

  • Feature-flagged injection: "IMPORTANT: Be extra concise. If you can say it in one sentence, don't use three."
  • Custom output style: (whatever depth-oriented instructions the user wrote)

The feature-flagged section appears before the custom output style in the prompt and uses IMPORTANT: emphasis, giving it structural priority. Users have no way to disable the feature flags or opt out of the A/B test.

The three-tier A/B test means different users experience different intensity levels with no visibility into which tier they're on. The strict tier ("CRITICAL: Be extremely concise. Use the fewest words necessary.") would be particularly damaging for creative or analytical work.

Suggested Fix

The feature flag injection code path needs to check whether a custom output style is active and skip conciseness injection if so — matching the documented behavior. Alternatively, provide a user-facing setting to opt out of conciseness injection entirely.

Environment

  • Platform: macOS (darwin)
  • Versions tested: 2.1.56, 2.1.66, 2.1.68, 2.1.69
  • Output style: Custom, set via outputStyle in .claude/settings.json

Workaround

Explicit direct-negation overrides in the output style markdown that quote and countermand each specific injected directive. This works but shouldn't be necessary — the documentation promises stripping, and the feature flags should respect it.

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗