Claude Remote Control stuck at Capacity: 0/32

Remote Control on my server says Ready, but I can't do anything in the app. Find out why in the debug log and fix it.

Many of our customers run Remote Control as a permanent service on their server, so a Claude Code session is always waiting on their phone. Sometimes everything looks fine and nothing works. This article covers the cause we ran into twice, and which a restart does not fix.

What exactly do you see?

In the Claude app the session does not open, or you get "Remote Control disconnected" or "bridged Claude Code process stopped responding mid-turn".
On the server the host reports Ready, but with Capacity: 0/32. There is not a single session running that you can type into.
The service window only says "Session failed".
Restarting the service does not help. Rebooting the server does not help either.

What causes it?

Claude's project folder, for example ~/.claude/projects/-home-jan/, contains a file called bridge-pointer.json. It records which session the host picks up again when it starts. If that session no longer exists on Anthropic's side, or has just failed, picking it up fails. The session the host creates at startup stops within a second. The file stays where it is, so every restart does exactly the same thing.

In the debug log it looks like this:

[bridge:init] reconnectSession(...) failed: 400 Session not found
<<< control_request {"reason":"archived","subtype":"end_session"}
[ERROR] CCRClient: Epoch mismatch (409, reason=unattributed), shutting down

The first time, the file pointed to a session from weeks earlier that had since been archived. The second time, the file was fresh: it pointed to the session that had failed during that very startup. So this is not only a problem with old files.

How do you find the real error?

The service window only says "Session failed". You only see the reason when you start the host yourself with a debug log. Stop the service first, otherwise two of them run:

systemctl --user stop claude-rc          # the name of your service
claude rc --verbose --debug-file /tmp/rc-debug.log

claude rc is short for claude remote-control. The child process writes its own log, /tmp/rc-debug-<id>.log, and that is where the real reason for the session stopping appears. Run this in tmux or screen so it keeps going if your SSH connection drops.

How do you fix it?

Move the file aside and start the service again:

systemctl --user stop claude-rc
cd ~/.claude/projects/-home-jan/
mv bridge-pointer.json bridge-pointer.json.bak
systemctl --user start claude-rc

The host creates a new bridge-pointer.json. Within a few seconds it shows Connected and Capacity: 1/32.

Note: the environment gets a new ID in the process. Pick the new environment in the Claude app, or scan the QR code again. An old bookmark to the session no longer works.

Why you should not let Claude restart its own service

A second pitfall feels the same but has a different cause. Ask a Remote Control session to "quickly restart Remote Control", and Claude restarts the service it is running in. Every running session stops in the same second, with exit code 144.

The journal shows the difference:

Stopping … means someone asked for the stop, for example Claude itself.
Scheduled restart job means the process fell over and systemd started it again.

We gave the service's management script a check. It refuses to stop or restart when it is called from inside the service itself:

if grep -q 'claude-rc\.service' /proc/self/cgroup; then
  echo "Refused: this session runs inside claude-rc.service" >&2
  exit 3
fi

If the restart really has to happen, schedule it separately from the session. The session ends, but the service comes back:

systemd-run --user --on-active=3 systemctl --user restart claude-rc

Common mistakes

Restarting again and again. As long as bridge-pointer.json points to a dead session, every restart gives the same result.

Deleting the file. Move it aside with .bak on the end. Then you can still see later which session it pointed to.

Only looking at the service window. "Session failed" says nothing about the reason. That is in the child process's debug log.

Still using the old bookmark. After the fix the environment ID is different.

Looking for it in the firewall. The host calls out to Anthropic itself. A blocked IP address on your side affects SSH or mail, but not Remote Control.