2026-08-07

CloudCLI (claudecodeui) Stuck on "Processing" or Shell Frozen on Mobile?

If you're self-hosting CloudCLI (also known by its repo name, claudecodeui) and mobile Safari either loses a chat response mid-stream or the Shell tab stops updating after you background the app — this is a known, publicly tracked situation, not something specific to your setup. There are two separate open issues for it. Restart or Disconnect is the immediate move; here's why, and what's actually going on underneath.

Two separate symptoms

• Chat freezes mid-response. On iOS Safari, a streaming reply drops partway through and the UI just sits on "Processing" — no error, no retry, nothing comes back.
• Shell panel goes stale after backgrounding. Put the app in the background or lock the phone, come back, and the Shell tab has stopped showing new output — even though the underlying agent process is still running, which you can confirm because the Chat panel keeps advancing normally.

What to do right now

For both symptoms, the fix reporters confirmed works is manually hitting Restart or Disconnect on the stuck session — it's a workaround, not a permanent fix, but it's the one documented path back to a working state.

The two issues, and their root causes

Issue #554 (opened 2026-03-17, open at time of writing) covers the chat-freeze symptom. The reporter states mobile Safari is "currently unusable for interactive chat" under this condition, and their requested fix reads:

Responses should be buffered server-side and replayed on reconnect.

(Reported by a user; not reproduced by us)

Issue #953 (opened 2026-07-02, open at time of writing, filed against v1.35.1) covers the Shell-freeze symptom. The reporter's code-level analysis points to the server pinging every 30 seconds but never listening for the corresponding pong, never tracking connection liveness, and never calling terminate() on a half-open socket — combined with iOS not sending a FIN packet when a backgrounded tab's socket effectively dies, data ends up written into a connection that looks open on the server side but has been dead for a while. (Reported by a user; not reproduced by us)

Where the manual fix falls short

Restart/Disconnect is reactive — you find out something broke, then you fix it, and if it happened mid-task, that task got interrupted. Avoiding backgrounding entirely would sidestep it, but that's not realistic on a phone that locks itself on a timer. And as of when this was written, both issues are open with no assignee, so there's no committed timeline for either landing upstream.

What CloudCLI does better

It's worth being straightforward about this before going further: CloudCLI is 13,158 stars and 1,804 forks as of 2026-08-07, against PocketShell's much smaller base — that gap is real, and it also tells you something useful, which is that self-hosted mobile access to coding agents is a real, validated need. (Source: official repo) Concretely, where it's ahead:

• Ecosystem and scale. A large, active user base and issue tracker, plus support that's grown beyond Claude Code to OpenCode, Cursor CLI, and Codex — one interface across multiple coding agents, not just one. (Source: official repo)
• A chat-first interface. For someone less comfortable with a raw terminal, a chat UI with an attached shell is a genuinely friendlier entry point — this is a different design tradeoff, not a worse one.
• A hosted option. CloudCLI Cloud is a commercial offering that's already live — the README lists it first in Quick Start, marked "(Recommended)," starting at €7/month, and its FAQ states plainly: close your laptop, the agent keeps running. That's something no self-hosted tool, PocketShell included, can offer by definition. (Source: official repo)

Where PocketShell's architecture differs

This is a description of a design difference, not a claim that PocketShell is immune to every failure mode above — we haven't run it through the scale CloudCLI has, and there's no independently audited track record to point to either way. What can be said concretely: PocketShell tracks connection liveness with heartbeat ping/pong plus a separate staleness timeout, rather than relying only on the socket's own onclose/onerror events firing — the two-signal approach is specifically there to catch a connection that looks open but has gone quiet. Reconnects request everything missed since a tracked sequence number from a server-side ring buffer, rather than assuming the original socket object is still valid. And the top bar shows a live connection-state dot plus a disconnect banner, so a break is visible rather than silent.

One structural difference worth naming plainly: CloudCLI runs Chat and Shell as two separate channels (a /ws connection plus file watching for one, an independent /shell WebSocket for the other) — which is how a chat panel can keep advancing while the Shell panel freezes, since they're not the same connection. PocketShell is built around a single tmux/PTY session model instead. These aren't the same shape of system, so it's not a strict "better/worse" comparison — just a different answer to the same problem.

Which one to reach for