[BUG] macOS: Desktop /resume shows session's folder isn't trusted yet for CLI-only sessions despite folder being trusted

Preflight Checklist

• [x] Searched existing issues — closest match is #60341 (Windows), same root

mechanism (CLI-spawned sessions lack a Desktop-native pointer/wrapper
record and are filtered/blocked), different platform and failure mode
(invisible on Windows vs. misleading trust error on macOS)

• [x] Single bug report
• [x] Using latest version

Environment

• Claude Desktop: 1.34493.1 (macOS, native install)
• Claude Code CLI: 2.1.245
• macOS 26.6.2 (build 25G83)

What happened

A session started purely via the claude CLI binary (never opened in
Desktop) appears in Desktop's /resume search dialog, but selecting it
fails with: "That session's folder isn't trusted yet. Start a session in
that folder first, then try again."

The folder IS already trusted — ~/.claude.json → projects["/Users/x"].hasTrustDialogAccepted is true, and other sessions in the same folder
resume fine from Desktop.

Root cause (verified by inspection)

Desktop maintains its own session index separate from the CLI's
~/.claude/projects/*.jsonl transcripts:
~/Library/Application Support/Claude/claude-code-sessions/<window-uuid>/<workspace-uuid>/local_<uuid>.json

Each wrapper file has a cliSessionId pointing at the real transcript.
Only sessions that originated in (or were previously opened by) Desktop
get a wrapper. In my project dir, 135/187 CLI transcripts had a wrapper;
52 did not.

Desktop's /resume dialog lists sessions directly from the CLI transcript
store (hence CLI-only sessions appear at all), but attaching to one that
lacks a wrapper apparently re-runs some bootstrap/trust check that fails —
even though the underlying ~/.claude.json trust flag is already true.
The error message is misleading; the actual gate is "no Desktop session
record exists for this transcript," not folder trust.

Repro

1. Run a session purely via claude CLI (never open Desktop in that

session) in an already-Desktop-trusted folder.

1. In Desktop, type /resume, find that session in the search dialog.
2. Select it → "session's folder isn't trusted yet" error, even though

other sessions in the same folder resume normally.

Attempted workaround (does not work)

Hand-crafted a local_*.json wrapper file matching the schema of a real
Desktop-created one (same cliSessionId, cwd, full field set including
completedTurns, alwaysAllowedReasons, reportFindingsCard, spawnSeed,
empty remoteMcpServersConfig). After restarting Desktop, the session
stopped appearing in /resume at all — worse than the original error,
suggesting Desktop does real validation against fields/format not
documented anywhere, or dedupes against the transcript-scan fallback once
a (even invalid) wrapper file exists for that cliSessionId.

Expected behavior

Desktop should either (a) transparently adopt a CLI-only session by
writing its own wrapper on first attach, using the already-verified
~/.claude.json trust state, or (b) not list CLI-only sessions in
/resume at all if they can't actually be opened, rather than showing a
false trust error.

Related

#60341 — same underlying pattern on Windows (CLI-spawned session pointer
files lack Desktop's entrypoint marker and are filtered from the
sidebar), confirms this isn't macOS-specific in cause, just in surface
behavior.