[BUG] Desktop (macOS): Claude Projects threads on a local folder create hidden phantom sessions, and approvals and notifications send you there

Same on Windows (Claude desktop app, Code tab), and it's worse there: the session can end up completely unreachable.

Steps

1. In a Claude Project, a thread starts a Remote Control session on a local folder on my Windows PC.
2. That session pings and a Windows desktop notification appears.
3. Click the notification. At first this opened the backing Code session.
4. Look for that session in the Code tab sidebar.
5. Later, click another notification from the same session.

Expected: the session is listed in the sidebar (ideally linked to its Project thread), or the notification opens the Project thread itself.

Actual:

• The session is never listed in the sidebar or past sessions.
• Clicking the notification used to be the only way in. Now it no longer opens the session either.
• So there is no route at all into a live session that is running on my own machine and pinging me. I have to relay everything through the Project thread.

Environment: Windows 11 Home 26H2 (build 26300), Claude desktop app 2.19675.0.0, Project thread on a local folder via Remote Control.

Possibly related: #90156 (Windows notification click leaves the window frozen).

---
_Generated by Claude Code_

Additional Windows findings from October 7, 2026: the pin persists in local metadata, but the Code sidebar does not display the session.

Environment

• Windows 11 Pro, build 26200, x64.
• Claude desktop app 2.26454.2.0.
• Projects beta, with a thread on a local folder through Remote Control.

Observed behavior

1. A Project thread creates a local Code session that runs its work.
2. That Code session opens and accepts further work.
3. Claude reports that it pinned the session.
4. The session remains absent from the Code sidebar. Claude's sidebar inspection reports zero sessions in its Pinned section.

A read-only inspection of the exact session record under %APPDATA%\Claude\claude-code-sessions\<account>\<org>\local_<id>.json confirms:

{
  "isStarred": true,
  "isArchived": false,
  "remoteControlSpawn": {
    "projectThreadChild": true,
    "rcChild": true
  }
}

The direct claude://claude.ai/epitaxy/local_<id> link identifies the same saved local session. Its record and the task's output files remain on disk. This points to a sidebar visibility or session-index problem, rather than failure to persist the pin.

One diagnostic caveat: the normal list_sessions tool deliberately excludes its own caller. A result with only one other session does not establish that the current session disappeared. The relevant evidence here is the saved pin state plus the missing sidebar entry. Anthropic documents this limit.

The record retains cached Remote Control identifiers. Those identifiers do not establish a live connection. I did not verify the reported connection loss or the cause of the sidebar exclusion.

Expected: a pin accepted by a local Code session appears in the sidebar. If the sidebar cannot display Project workers, the app explains that restriction and provides a reliable route back to the Project thread.

No session metadata or application files changed during this inspection. Account identifiers, session identifiers, and private paths are omitted from this comment.

Same on Linux (Ubuntu 26.04.1 LTS, LXQt, Claude Desktop 2.31226.0, Project thread on a local folder via Remote Control).

Everything described above matches: the backing Code session is not in the sidebar, it shows the raw <wake> / <project> / <message> envelopes, and the terminal that the agent opens with Run In Terminal is not visible anywhere in the Project thread (also not when the thread is popped out into its own window). The only way I found to reach it was xdg-open "claude://claude.ai/epitaxy/<session_id>".

One more inconsistency on top of that: the ⋮ menus differ between the two views.

• Backing Code session (the one with the terminal): the ⋮ menu only has "Keep computer awake".
• Project thread: the ⋮ menu has Copy link, Copy ID, Rename, Pin, Resolve, Report a problem, Delete.

So from the view where the terminal actually lives, there is no way to report a problem.

_Written with Claude Code, verified on my machine._