/exit is denied ("isn't available in this environment") in sessions spawned by `claude remote-control` server mode — no clean way to end a remote session from either side

Status Open

Reported on v2.1.217

Maintainer reply None cached

Activity 3 comments · opened Jul 22, 2026

Summary

/exit sent from a remote client (Claude mobile app / claude.ai/code) is denied with:

/exit isn't available in this environment.

but only for sessions spawned by claude remote-control (server mode). Combined with the other limitations below, there is currently no clean way to end a server-spawned remote session from either side.

Environment

Claude Code 2.1.217, Windows 11, Max plan
Server: claude remote-control --name my-vault (spawn=same-dir, launched at logon via Task Scheduler)
Client: Claude mobile app

Repro

Run claude remote-control (server mode) on the host.
From the mobile app, connect to the device and start a new on-demand session.
Send /exit from the client → /exit isn't available in this environment.

Control experiment (why I believe this is the non-interactive denylist)

With an interactive TUI session on the same host (claude --remote-control, same binary 2.1.217) mirrored to the same phone, /exit sent from the phone works: the CLI process exits and the session is archived.

So the denial only affects server-spawned (headless) sessions, which are presumably classified as isNonInteractiveSession and hit the denylist analyzed in #63988.

Why this matters — no termination path at all for server-spawned sessions

/exit from the client: denied (above)
claude stop <name> on the host: fails with No job matching '<name>' — the session appears in claude agents --json as "kind": "interactive", so the background-session stop path doesn't apply
Killing the PID on the host: works, but claude.ai keeps showing the session as "Connected" indefinitely (no disconnect event reaches the backend; reopening the ghost session gives the #60790 behavior). The only cleanup left is manually archiving it in the app.

Stale sessions permanently occupy the server's capacity slots (--capacity, default 32).

Docs conflict

remote-control.md lists /exit among the text-output commands that "work from mobile and web"
The v2.1.81 changelog entry — "Remote Control /exit not reliably archiving the session" — shows /exit is the intended cleanup path for Remote Control sessions (see #36856)

Expected

/exit from a remote client should end and archive a server-spawned session, freeing its capacity slot — or, at minimum:

docs should state that server-spawned sessions cannot be exited remotely, and
sessions whose CLI process is gone should eventually show as Disconnected instead of Connected forever.

Related: #63988, #36856, #28351, #60790

View original on GitHub ↗

3 Comments

Flint8777 · 1 month ago

Temporarily withdrawing to review the report content. Will reopen after revision.

Flint8777 · 1 month ago

Reviewed and revised (removed an environment-specific name). Reopening.

madciapka · 17 days ago

Confirming on Linux — same behavior, still present in 2.1.231.

Host: claude rc (Linux 7.0.0-28-generic x86_64), capacity 2/32
Client: Claude mobile app, session created on-demand in the current directory

/quit from the phone is denied with /quit isn't available in this environment. — same denylist path as /exit in the original report. From the mobile client there is no way to end the session at all; the only working option is walking back to the host terminal and Ctrl+C'ing the claude rc process, which also tears down every other session it hosts.

The practical effect matches the report: sessions you can start from anywhere can only be ended from the one machine you started them on, and abandoned ones sit on capacity slots.

+1 on the minimum ask in the issue — either let a remote client end its own session, or expose a per-session stop in the app so the host terminal isn't the only exit.