[BUG] The Claude Desktop app (Linux beta) never displays the correct permission mode or effort level for sessions spawned from the Claude Code CLI

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

Here's the full bug report:

---

What's Wrong?

The Claude Desktop app (Linux beta) never displays the correct permission mode or effort level for sessions spawned from the Claude Code CLI. It consistently shows wrong/default values regardless of what flags were passed at spawn time.

What Should Happen?

The Desktop app's session list should accurately reflect the permission mode (e.g. auto, default, bypass-permissions) and effort level (e.g. xhigh, high, low) that each CLI-spawned session was started with.

Error Messages/Logs

No error messages. Silent data gap — the Desktop app renders without crashing but displays incorrect metadata.

Steps to Reproduce

1. Spawn a background Claude Code session with explicit permission and effort flags:

``
claude --bg --permission-mode auto --effort xhigh -n my-test-session "do some work"
``

1. Open the Claude Desktop app on Linux.
2. View the session list / agents panel — observe that my-test-session shows wrong or missing values for permission mode and effort.

Root cause (confirmed by inspection of on-disk data):

The CLI daemon never writes effort or a normalized permissionMode field to the two sources the Desktop app reads:

~/.claude/daemon/roster.json — worker entries have a dispatch.launch.args array that includes --permission-mode only when it was an explicit CLI arg (sessions that inherit from settings or use the default have nothing). The --effort flag is never serialized here at all, regardless of how the session was spawned. There is a decModes array with numeric codes (e.g. [1000, 1002, 1003, 1006, 2004, 1004, 2031]) but these are not surfaced as human-readable permission metadata.

~/.claude/sessions/*.json — these files record kind, cwd, name, status, entrypoint, bridgeSessionId, etc., but contain no effort field and no permissionMode field whatsoever.

Example roster entry (real data, truncated to relevant parts):

{
  "dispatch": {
    "launch": {
      "args": [
        "--session-id", "7b0507e2-...",
        "--permission-mode", "auto",
        "--model", "claude-fable-5",
        "-n", "my-session-name",
        "...prompt..."
      ]
    }
  },
  "decModes": [1000, 1002, 1003, 1006, 2004, 1004, 2031]
}

Note: --effort xhigh was passed at spawn but does not appear anywhere in the serialized record.

Example session file (~/.claude/sessions/<pid>.json):

{
  "pid": 2509776,
  "sessionId": "3470751c-...",
  "cwd": "/home/jasmin/ferroclasm",
  "startedAt": 1783074450457,
  "kind": "bg",
  "entrypoint": "cli",
  "name": "my-session-name",
  "status": "idle"
}

No effort, no permissionMode.

The Desktop app cannot display values that are never written to disk. This is a serialization gap in the CLI daemon's session/worker registration path.

Is this a regression?

Unknown — this is a new Linux beta install; no prior version to compare against.

Claude Code Version

2.1.199 (Claude Code)

Platform

Anthropic API (claude.ai subscription / claude-code CLI)

Operating System

Ubuntu 24.04 LTS — Linux xubuntu 6.17.0-35-generic #35~24.04.1-Ubuntu SMP x86_64

Terminal/Shell

bash (/bin/bash), running inside Claude Desktop's integrated terminal as well as standalone terminal (xterm/bash)

Additional Information

The fix should be in the CLI daemon's worker/session registration code — specifically the path that writes new entries to ~/.claude/daemon/roster.json and ~/.claude/sessions/<pid>.json. Both should gain:

• A normalized permissionMode field (the resolved value, not just a raw CLI arg passthrough)
• An effort field (the resolved value)

The decModes array in roster entries may already encode permission decisions internally — if so, the Desktop app needs to know how to map those codes to display names, or the daemon should also write a human-readable permissionMode string alongside it.

---

That's ready to paste in. The key value of the report is the actual JSON excerpts proving the data is absent from disk — that makes it unambiguous and easy to reproduce on their end.
Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_