claude-code - 💡(How to fix) Fix Desktop app silently creates settings.json with effortLevel: high on first launch, causing unexpected API cost spike [1 participants]

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…
GitHub stats
anthropics/claude-code#54913Fetched 2026-05-01 05:51:08
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×4

First-ever launch of the Claude Code desktop app silently created ~/.claude/settings.json with effortLevel: high — without any prompt, confirmation, or visible indicator. This overrode the existing default behavior used by all other sessions (CLI/PowerShell), and the change went unnoticed until a billing review revealed a dramatic cost spike.

Root Cause

  • effortLevel: high enables extended thinking on every turn, dramatically increasing output token consumption
  • All subsequent sessions (CLI, PowerShell, and desktop) inherited this setting
  • No visible indicator in the UI showed that high effort was active
  • Result: approximately $85 in unintended API spend over ~30 hours before the setting was discovered by manually inspecting the settings file
  • User had no reason to check ~/.claude/settings.json because they had never modified it

Code Example

{
  "effortLevel": "high"
}
RAW_BUFFERClick to expand / collapse

Summary

First-ever launch of the Claude Code desktop app silently created ~/.claude/settings.json with effortLevel: high — without any prompt, confirmation, or visible indicator. This overrode the existing default behavior used by all other sessions (CLI/PowerShell), and the change went unnoticed until a billing review revealed a dramatic cost spike.

Environment

  • Platform: Windows 11 Pro
  • Claude Code version: 2.1.121 → 2.1.123 (updated around same time)
  • Prior usage: CLI and PowerShell exclusively
  • First desktop app launch: 2026-04-29 ~23:34 CT

Reproduction Steps

  1. Have an existing Claude Code setup using CLI/PowerShell with no ~/.claude/settings.json
  2. Launch the Claude Code desktop app for the first time
  3. Observe that ~/.claude/settings.json is created with effortLevel: high

What Was Created

{
  "effortLevel": "high"
}

File birth timestamp confirms it was created during that first desktop app session — it did not exist before.

Impact

  • effortLevel: high enables extended thinking on every turn, dramatically increasing output token consumption
  • All subsequent sessions (CLI, PowerShell, and desktop) inherited this setting
  • No visible indicator in the UI showed that high effort was active
  • Result: approximately $85 in unintended API spend over ~30 hours before the setting was discovered by manually inspecting the settings file
  • User had no reason to check ~/.claude/settings.json because they had never modified it

Expected Behavior

  • The desktop app should not write effortLevel: high (or any non-default setting) to settings.json on first launch without explicit user action
  • If effort level is configurable in the desktop app UI, the selected value should be shown prominently and changes should require deliberate user confirmation
  • The desktop app should inherit existing settings rather than overwriting them with elevated defaults

Notes

  • The effortLevel: high setting affects all Claude Code entry points globally (CLI, PowerShell, desktop), making it especially impactful when set silently
  • Discovery only happened through manual investigation of a billing anomaly — there is no in-product signal that effort level has been changed or that extended thinking is active
  • Anthropic's usage dashboard confirmed the token spike but does not surface per-setting attribution, making root cause analysis difficult for users

extent analysis

TL;DR

The desktop app should be modified to not write effortLevel: high to settings.json on first launch without explicit user action, and instead inherit existing settings or use default values.

Guidance

  • Review the desktop app's launch logic to ensure it does not override existing settings with elevated defaults.
  • Consider adding a prompt or confirmation step when the desktop app is launched for the first time to configure settings like effortLevel.
  • Implement a visible indicator in the UI to show when effortLevel: high is active, to prevent silent changes.
  • Update the app to require deliberate user confirmation for changes to settings like effortLevel.

Example

No code snippet is provided as the issue does not contain sufficient information about the app's codebase.

Notes

The solution may require changes to the desktop app's configuration and UI to ensure that settings are handled correctly and users are aware of changes.

Recommendation

Apply a workaround by manually setting the effortLevel to a default or desired value in the settings.json file until a fixed version of the desktop app is available, to prevent unintended API spend.

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

claude-code - 💡(How to fix) Fix Desktop app silently creates settings.json with effortLevel: high on first launch, causing unexpected API cost spike [1 participants]