Claude Code problem

all things rabbit
1

To use Claude Code on my Rabbit, I followed everything in the guide: I installed the agent on my PC and the installation was successful. Then, on the Rabbit, I swipe left twice; a little rabbit icon appears below my PC’s name and the time, with the text “starting Claude…” above it. It just stays like that—it doesn’t do anything. Even if I open or close Claude on the PC, log in, or do anything else, it just sits there; nothing happens. It cycles through “retrying,” “connecting,” and “starting Claude,” and then stops. If I press the talk button once, nothing…if I press “click to connect,” it starts the cycle all over again—retrying, connecting, starting Claude… So, what am I doing wrong? What should I do?

2

Are you using the Claude CLI (in terminal?) It doesn’t work with the desktop app.

If so, please try this:

1 - Revoke all nodes from rabbithole
2 - Register a new node and run the command in terminal again to install the agent
3 - Press PTT button 5x on r1

It should work after this.

3

Windows 11 user here.

At the risk of sounding silly, does it matter if it’s terminal or powershell?

(Not really al that silly, because I know that computers get cranky about the darnedest things.)

I have an R1 that I got a few weeks ago.

I recently subscribed to Claude Pro, and installed it on both powershell and the desktop, I added the node on the Rabbit Hole site, and the name of my computer is displayed on my Claude screen on the R1. So I know it can see my computer.

I have powershell running claude. sitting open even as I type. Still, all I get are “Starting Claude” and “Retrying”, back and forth.

4

Adding: sometimes, but not every time, when the R1 says “retrying”, a new powershell.exe window opens up.

5

Same loop here, and I think I found the mechanism behind it.

r1 on rabbitOS 2.2, rabbit-agent 0.1.3, macOS 15.5, Claude Code CLI at /opt/homebrew/bin/claude. Agent installed from Terminal against a freshly registered node. simon, I ran your three steps (revoke all nodes, register new, install from Terminal, PTT 5x) plus a full device restart. Identical before and after.

Agent side is healthy throughout: Status: connected, heartbeats every 30s, doctor passes, claude and node resolve on PATH.

Symptom: the first prompt after connecting works. Every prompt after that appears to hang, then returns nothing useful.

What the agent logs show. Counting "type":"user" events in each job’s stdout under ~/.rabbit-agent/jobs/claude-session-*/stdout, only 1 of 10 sessions ever received a prompt:

18:38  user=11  31438ms  (real work, ran tools)
18:23  user=0    2338ms  "I'm here, what would you like me to do?"
19:08  user=0    2311ms  "I'm here, what would you like me to do?"
19:51  user=0    5042ms  "I'm here, what would you like me to do?"
20:23  user=0    2632ms  "I don't see a request yet."
20:28  user=0    3000ms  "I'm here, what would you like me to do?"

The one working session ran 31 seconds and did real tool work. Every session after it started, found no prompt, emitted a generic greeting, and exited terminal_reason: completed in 2 to 5 seconds. Nothing is timing out and nothing is slow. The sessions are simply empty.

Likely related: the sessions never exit. Spawned claude -p processes do not terminate. Ten accumulated over six hours, oldest at 2h26m, holding roughly 5% of system RAM, all idle at 0% CPU. The agent log had already reported each as exited (completed) while the process was still alive.

That would explain the pattern: the first session works but leaks, and every later prompt spawns a fresh empty session instead of reaching the one still holding the conversation. On the r1 an empty session is indistinguishable from a hang, which I suspect is the retrying / starting Claude cycle you are both seeing.

Ruled out locally: working directory, PATH, desktop app versus CLI (confirmed it spawns the CLI binary), network, and node registration.

MaxCancer, gabey8, worth checking on your machines whether old sessions are piling up:

ps aux | grep "claude -p" | grep -v grep

Happy to share full job stdout or agent logs. The pattern reproduces on every attempt.

6

It seems I haven’t got grep on my computer. Both claude and the powershell gave that error.

Having said that, claude did its best to execute the command, and it was only able to identify its own running process.

In my case, though, I have not yet been able to get past the “connecting” screen. I haven’t actually connected to Claude yet.

7

papepi’s diagnosis matches what I hit independently, on a much newer agent build, so the leak isn’t version-specific.

Setup: r1 + rabbit-agent 0.1.9 on macOS (Darwin 25.6), Claude Code CLI resolving fine on PATH. papepi was on 0.1.3, so this has survived a lot of point releases.

Confirming the core finding: spawned claude -p processes never exit. I had four alive at once, the oldest 12-15 hours old, each still holding its stdin FIFO open with a live child process. The exit file in the job directory was empty the entire time, which is how the daemon marks “still running”, so its bookkeeping contradicts itself. Same divergence papepi saw where the log reports exited (completed) while the process is still alive.

The device symptom follows from that. The r1 exposes a single session slot, so several “running” sessions leave it unable to resolve a current one. Mine reported “no active claude session” while the Mac was entirely healthy, daemon up and control WS connected.

One thing I have not seen mentioned: the sessions are created in pairs. Job directory names carry epoch-ms plus an index, and -1788371073518-65 and -66 were created in the same millisecond, -1788371122554-67 and -68 1ms apart, -1788436041125-1 and -2 577ms apart. Only one twin of each pair is ever used. No way to tell from outside whether that is deliberate (a warm spare?) or a double-dispatch, but with nothing being reaped it is what fills the slot up.

Workaround: from ~/.rabbit-agent/jobs, run find . -maxdepth 2 -name exit -empty. An empty exit file means the daemon still thinks that job is running. Then kill -TERM the stale runner and its claude child. The daemon reaps them cleanly, logging exited (code=143), and the r1 reconnects immediately, with no re-registration or PTT dance needed. I have put that on a 5-minute timer and the device has stayed responsive since.

One warning while poking around: do not cat a job’s stdin. It is a FIFO and will block your shell until a writer appears.

Separately, nothing prunes the job directories. Mine had reached 1208 dirs and 20MB, of which 1143 were hermes-session- and openclaw-session- attempts for slots that are not installed on this machine. They die instantly with exitCode: null and retry with no backoff.

MaxCancer and gabey8, I suspect yours is a different failure, since you never get past “connecting” at all, whereas papepi’s and mine connect first and then leak. gabey8, you are on Windows so this will not map directly, but on macOS one cause of a silent never-connects loop is the daemon failing to resolve the claude binary. launchd starts it with a minimal PATH, and install.sh rewrites the LaunchAgent plist from a hardcoded template every 600s, so adding EnvironmentVariables to it does not stick. Worth checking ~/.rabbit-agent/logs/agent.log for sessions that launch and immediately exit with code=null.

9

aa13, that closes it for me. Your 0.1.9 numbers against my 0.1.3 mean this has survived six point releases untouched, and the empty exit file is the cleaner tell than anything I had. I was reading the agent log, which claims exited (completed), while your check reads the daemon’s own bookkeeping, which still says running. When those two disagree, believe the file.

The pairing is new to me and I think it explains the last gap in my data. I counted ten leaked processes over six hours and one working session out of ten prompts. If jobs are created in twins and only one twin is ever wired to a prompt, then the odds of a given prompt landing on the used twin are exactly what I measured, and the “empty session that greets you and exits in 2 to 5 seconds” is simply the unused twin being asked to answer. I cannot tell from outside either whether that is a warm spare or a double dispatch. What is certain is that nothing reaps either one.

So the failure is a lifecycle bug, not a transport bug. The control WebSocket is fine, registration is fine, PATH is fine, the network is fine. Sessions are spawned, never reaped, and the device exposes a single session slot, so once a few stale runners exist the r1 can no longer resolve a current one. On the device that is indistinguishable from a hang, which is why this thread has people re-registering nodes and doing PTT dances that cannot possibly help. Registration was never the broken part.

aa13’s reaper is the right workaround until rabbit fixes it. From ~/.rabbit-agent/jobs, find . -maxdepth 2 -name exit -empty finds jobs the daemon still believes are running, then kill -TERM the runner and its claude child. The daemon reaps cleanly and the device reconnects with no re-registration. Heed the warning about not cating a job’s stdin, it is a FIFO and will block your shell.

Two fixes on rabbit’s side would make the workaround unnecessary. Reap the child when the job is marked completed, so the log and the exit file cannot disagree. And route a prompt to an existing session for that working directory instead of spawning a new one, which is also what would make multi-turn conversation work at all. Right now the first prompt after connecting works and nothing after it does, which is the same symptom simon and MaxCancer opened with.

gabey8, yours is still a different failure. You never get past connecting, so there is nothing to leak yet, and on Windows none of the commands in this thread map directly. grep does not exist there. In PowerShell the equivalent look is Get-CimInstance Win32_Process | Where-Object CommandLine -like '*claude*'. More useful for you is the agent log, whatever the Windows equivalent of ~/.rabbit-agent/logs/agent.log turns out to be. What you are looking for is sessions that launch and exit immediately with a null exit code, which means the daemon cannot find the claude binary at all. aa13 named the macOS version of this: the service starts with a minimal environment that does not include wherever your package manager put claude, and editing the LaunchAgent does not stick because the installer rewrites it from a template every ten minutes. On Windows the analogue would be the service environment missing your npm global bin directory. Confirming which of those it is from your log is worth more than another round of re-registration.

On macOS, for anyone stuck on the same PATH problem, sudo launchctl config user path sets the PATH that user services inherit and survives the installer rewriting the plist, at the cost of a reboot. I have not tested that against this specific daemon, so treat it as a lead rather than a fix.

One last thing that is not this bug but gets mistaken for it. If sessions do connect and answers still take minutes, look at transcript volume before blaming the model. The r1’s Claude tab enumerates local sessions and the agent streams those transcripts to rabbit’s cloud in 64KB chunks to do it. I had 393MB across 316 files, nine of which were 269MB on their own, which is thousands of round trips before the device can show you a list, repeated per query. The signature is repeated readFile ... read 65536 bytes lines against ~/.claude/projects/ in the agent log. Archiving files over 10MB took mine to 125MB and the delay went away. Cut on file size rather than age, since the largest ones were only days old.

Happy to share full job stdout and agent logs from the August run if anyone from rabbit wants them.