Projects: keep a folder's "default local folder" approval when its Remote Control server restarts

Status Open
Reported on v2.1.284
Maintainer reply None cached
Activity 1 comment · opened Sep 30, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

I run 25 Claude Code Projects. Each has a default local folder on one Linux laptop, served by claude remote-control --spawn worktree, one server per repo, started at login.

When a server restarts, for example after a reboot or a long network drop, it can register under a new environment id. The Project's folder approval still points at the old id. From then on the Project's threads show "Lost contact with your folder" or "~/code/my-repo is offline, your message is waiting", although the server is running and connected. Project settings shows the default local folder as "Not connected".

Nothing tells me the approval went stale. I find out when a thread stalls. On 28 Sep 2026 this hit 21 of my 24 approvals at once, and on 29 Sep 2026 it hit 18 of 24. A thread that was running on the old id never reconnects, so its work has to restart in a new thread.

The approval also expires 30 days after the folder was last used, and there is no setting for that.

Proposed Solution

Bind the approval to the device and the folder path, not to the environment id. If a server for the same folder on the same device reconnects, the existing approval keeps working and waiting threads resume.

When an approval does stop matching a connected folder, say so in Project settings and in the thread, with a "use the connected folder" action that takes a single click.

Add an "until I revoke it" option next to the expiry of 30 days.

Alternative Solutions

Today I work around it with a systemd timer on the laptop. Every 5 minutes it reads each Project's approval, looks up the folder's current environment id, and posts the approval again when the two differ. It works, but it depends on an undocumented endpoint and it cannot rescue a thread that was already stranded.

Selecting the folder again by hand in each Project's settings also works. With 25 Projects that is 25 visits after every restart.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

  1. My laptop reboots overnight and the Remote Control servers start again at login.
  2. In the morning I message a Project thread that was working in ~/code/my-repo.
  3. Today: the thread answers "~/code/my-repo is offline, your message is waiting", and stays that way until I repair the approval and start a new thread.
  4. With this feature: the restarted server is recognised as the same folder on the same device, and the thread carries on.

Additional Context

Claude Code 2.1.284 on Linux, Max plan, Projects beta.

Related: #97058 (finished Project threads keep their sessions and fill the session cap).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗