Scheduled-task session runs but never appears in the desktop app sidebar

Summary

A session started by a scheduled task runs normally and is reported by the
session-management API, but never appears in the desktop app's session sidebar.
There is no way to reach it from the UI, and the ID the API reports for it
cannot be used with claude --resume.

Environment

• macOS (Darwin 25.5.0), Apple Silicon
• Claude Code desktop app, bundled CLI 2.1.229
• Standalone CLI on PATH: 2.1.200

Steps to reproduce

1. Create a one-time scheduled task via the scheduled-tasks MCP server, with a

prompt that runs a long multi-step job in a git repo.

1. Let it fire.
2. Open the desktop app and look for the session it created.

Expected

The session appears in the sidebar like any other, and can be opened to watch or
interrupt it.

Actual

It is not in the sidebar. The session is genuinely running:

$ ps -p 32298 -o pid,etime,command
  PID ELAPSED COMMAND
32298   17:53 .../Claude/claude-code/2.1.229/claude.app/Contents/MacOS/claude \
              --output-format stream-json ... --disallowedTools AskUserQuestion ...

~/.claude/sessions/32298.json confirms the desktop app launched it:

{"pid":32298,"sessionId":"e461dd01-...","cwd":"~/github/<project>",
 "procStart":"Sun Aug 16 16:30:25 2026","version":"2.1.229",
 "kind":"interactive","entrypoint":"claude-desktop"}

entrypoint is claude-desktop, so the app owns the process — it just does not
list it.

Secondary issue: unusable session ID

From another session, the list_sessions MCP tool reports this session as:

{"sessionId":"local_c545da07-...","title":"...","isRunning":true}

That local_-prefixed ID does not match the process's real sessionId
(e461dd01-...), and appears nowhere on disk under ~/.claude. So the obvious
recovery path fails:

$ claude --resume local_c545da07-...   # no such session

The working ID has to be recovered by hand, by listing
~/.claude/projects/<munged-cwd>/*.jsonl by mtime.

Two requests, in priority order:

1. Scheduled-task sessions should appear in the sidebar — they are long-running

and unattended, which is exactly when you want to watch them.

1. list_sessions should report an ID that --resume accepts, or expose the

underlying session UUID alongside it.

Impact

An unattended agent ran for 18 minutes making commits to a feature branch with
no way to observe or stop it from the UI.