Desktop app: 'Enable remote control by default' does not apply to sessions forked into a new worktree
Summary
In the Claude desktop app, with Settings › Claude Code › Enable remote control by default switched on, a session created by forking an existing session into a new git worktree does not connect Remote Control. Sessions started normally in the same app, same account, same repository do connect and appear in the Claude mobile app and at claude.ai/code; the forked one never appears.
Environment
- Claude desktop app 1.46388.4 (Code tab), macOS 26.3
- Claude Code 2.1.233
- Individual plan (no managed settings;
~/.claude/settings.jsonandsettings.local.jsonare both{}, so the desktop toggle is stored in the app's own configuration, not mirrored to the CLI settings file)
Steps to reproduce
- In the desktop app, turn on Settings › Claude Code › Enable remote control by default.
- Start a session in a repository the normal way. It connects: the session shows up in the mobile app.
- From that session (or another), use the app's fork action that creates a new session in a new worktree of the same repository (the forked session reports
originCwd= the repository root,sourceBranch=main,worktreePath=.claude/worktrees/<name>). - Work in the forked session for a while; check the mobile app.
Expected
The forked session auto-connects Remote Control like any other interactive session, since the default is on.
Actual
The forked session never connects. Inside it, the agent listing shows only local peer sessions and no Remote Control rows (the listing states other-device sessions appear "when Remote Control is connected here"), and the mobile app lists the two non-forked sessions from the same repository but not this one. The session has been running for more than a day (created 2026-09-11 18:14 UTC) across several turns, so it is not a timing issue at startup.
Notes
- The forked session was itself a continuation: its conversation was carried over from the parent session (compaction summary) into the new worktree.
- Nothing else about the session is unusual: same account, same model,
isRemote: falselike the peers, PR linkage present. - Workaround presumably
/remote-controlin the forked session; the report is that the default did not apply.
🤖 Generated with Claude Code