Project-scope effortLevel in .claude/settings.json is never applied in desktop-app (Code tab) sessions; effective effort varies per session with no settings change

Summary

With effortLevel: "xhigh" in ~/.claude/settings.json and effortLevel: "high" in the repository's .claude/settings.json, sessions started from the Claude desktop app's Code tab run at xhigh. The settings reference says the highest-precedence settings file that sets effortLevel decides, and project settings rank above user settings, so high was expected. Across a sweep of recent sessions the effective effort also varied between xhigh, high and max with no change to any settings file, which suggests the app selects effort per session and the settings chain is not consulted.

Environment

• Claude Code 2.1.260 and 2.1.263, launched from the Claude desktop app (Code tab), macOS (Darwin 25.6)
• ~/.claude/settings.json: "effortLevel": "xhigh", no modelSettings entry
• <repo>/.claude/settings.json: "effortLevel": "high" (committed; present in every worktree)
• Other project-scope keys in the same file are honored in these sessions (autoCompactWindow demonstrably triggers compaction at the configured size), so the file is being read

Steps to reproduce

1. Set effortLevel: "xhigh" in user settings and effortLevel: "high" in a repository's .claude/settings.json.
2. Start a new session on that repository from the desktop app and let it run a few turns.
3. Read the effective effort from the transcript, since there is no in-session way to see it:

``bash
grep -o '"effort":"[a-z]*"' ~/.claude/projects/<project-dir>/<session>.jsonl | sort | uniq -c
``

Expected

Every assistant record carries "effort":"high".

Actual

Every record carries "effort":"xhigh". In a sweep of 45 recent desktop sessions in one repository family (same user and project settings throughout) the effort was xhigh in most, high in 3 and max in 1; the same worktree produced xhigh in one session and high in the next 43 minutes later with no settings change. Headless claude -p sessions started by a plugin hook in the same repository also ran at xhigh.

Why it matters

Effort is the main lever a repository has to bound reasoning and tool-call volume for its own sessions, and the docs present the project settings file as the place to set it. If the app decides effort per session instead, that should be documented, and there should be a way to see the effective value inside a session (a /status or /effort line), because today the transcript grep above is the only reliable read and it is easy to conclude from settings.json that a setting is in force when it is not.

Related

• #87326 — Remote Control ignores settings.json effortLevel; same class of problem on a different surface
• #90229 — statusline effort level not updating; the introspection gap this report also runs into
• #93722 — connector handling in the same desktop-app worktree sessions