[Feature Request] Add session persistence and health-check mechanisms for remote channel operations
Bug Description
Feature feedback: Claude Code Channels — session resilience for remote operation
Context: I run Claude Code instances across multiple Hetzner servers (different codebases/workloads), managed remotely via phone. Channels is a natural fit for this — the plan is a Slack workspace with a dedicated channel per server instance. No terminal access during normal operation.
The problem: If the Claude Code process crashes, hangs, or the session dies for any reason, the channel goes silent with no way to recover remotely. The user has no indication whether Claude is thinking, stuck on a permission prompt, or dead. This is the single biggest barrier to using Channels as a genuine remote operations tool rather than a local convenience.
When you're at the terminal this is a non-issue — you see the crash, you restart. When you're operating remotely (which is the entire point of Channels), it becomes a blocking problem.
Suggested improvements:
- A --persistent or --daemon flag that auto-restarts the Claude Code session on crash, preserving the channel connection. Ideally with configurable retry backoff.
- A health-check mechanism that channel clients can poll, so the messaging side knows the session is dead rather than just unresponsive. Even a simple heartbeat that posts a status message to the channel on process exit would help.
- A remote restart capability — a reserved command (e.g. /restart) that the channel plugin handles independently of the Claude Code process, allowing it to respawn the session.
- Session state recovery — ability to resume the previous session context after a restart, so work in progress isn't lost.
The workaround today is a watchdog loop in tmux, which works but is fragile and outside the product. Native support for persistent remote sessions would make Channels genuinely production-ready for multi-server setups.
Great feature, solves a real problem — just needs the resilience layer for the remote-first use case it enables.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗