### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Related to #29156 Environment: Claude Code on the web — a remote execution container session started via an external trigger/automation (not a local clau

[BUG] Slash commands fall through as prompts in externally-triggered remote execution (web) sessions

Status Fixed / completed

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 5 comments · opened Jun 14, 2026 · closed Jun 15, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Related to #29156

Environment: Claude Code on the web — a remote execution container session started via an external trigger/automation (not a local claude CLI session, and not a standard claude remote-control session).
Reproduced on all three clients: web browser, desktop app, and mobile app — identical.
Symptom: Every slash command (/compact, /context, /clear, …) is not intercepted by the client. It is passed through verbatim as a normal chat message to the model — the assistant receives a user message whose content is literally /context, /compact, etc. No command UI or execution happens.
Impact: Because /compact and /context never reach the harness, there is no way to compact or inspect context in these sessions. Once context fills up, the only workaround is starting a brand-new session — painful for long working sessions.
Possibly same root cause as #29156, but the session type here is an externally-triggered remote execution container, which remote-control.md § Limitations doesn’t seem to cover — that section says /compact//context “work from mobile and web,” yet in this session type they fall through to the model.
Request: Either enable slash-command bridging for externally-triggered remote execution sessions, or document the limitation so users know context can only be managed by starting a new session.

What Should Happen?

Slash commands (/compact, /context, /clear, etc.) typed into the chat input should be intercepted and executed by Claude Code — e.g. /context shows context usage, /compact compacts the conversation. They should NOT be forwarded to the model as plain chat text.

Error Messages/Logs

None — there is no error message. The command silently falls through and is treated as chat input (the assistant replies as if the literal text “/context” had been typed). The absence of any feedback is itself part of the problem.

Steps to Reproduce

Open a Claude Code session on the web — specifically an externally-triggered remote execution container session (not a local claude CLI session, and not a standard claude remote-control session).
In the chat input, type any slash command, e.g. /context or /compact, and send.
Observe: the command is not intercepted. The assistant receives a normal user message whose content is literally /context / /compact — no command UI or execution happens.
Result: /compact and /context never reach the harness, so there’s no way to compact or inspect context. Once context fills up, the only workaround is starting a brand-new session.

Reproduced identically on web browser, desktop app, and mobile app.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.260604.0 (27047400567)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This reproduces identically across all three clients — desktop app, iPhone app, and web interface. None of them can execute slash commands; in every case the command is sent to the model as plain text instead of being intercepted and run.

View original on GitHub ↗

5 Comments

strobelleder · 4 months ago

One possible reason: The time stamp added to the command. The slash is no longer the first char.
When I send "/clear" from my Claude code app on Android to the remote session on my desktop, the terminal on the desktop shows:
"\<system-reminder\>Message sent at Sun 2026-06-14 12:37:32 UTC.\</system-reminder\>
/clear"
And Claude tries to answer. Says something about the session being cleared, whereas the status says it's still full.

TB1982 · 4 months ago

Follow-up (2026-06-15): two distinct failure modes observed

Did more testing today with the assistant. What looked like one bug turned out to be (at least) two separate failure modes:

Mode A — /compact starts, but the assistant's next turn interrupts it

After typing /compact, the UI does start compacting — the "Compacting conversation" indicator appears and its timer runs.
But the moment the assistant produces its next response (a new turn), the in-progress compaction is interrupted and disappears.
Contrast: the one time compaction did succeed, it happened while the assistant was running a continuous chain of tool calls (busy, without ending its turn / handing control back to me). Context dropped from ~30% → ~9% during that window. So compaction seems only able to complete in a window where the assistant is not generating a new turn.

Verification: I had the assistant type /compact then deliberately run a series of tool calls without ending its turn (to hold a "busy window"):

1st attempt: compaction ran for 1m01s, then stopped the instant the assistant ended its turn to reply — confirming the assistant's turn interrupts compaction.

Mode B — UI indicates compaction in progress, but nothing actually happens

Holding the busy window much longer (~8 real minutes, assistant never ending its turn): the "Compacting conversation" indicator appeared with a running timer that reached 8m28s, but no compaction ever took effect — context window stayed at 39% (388.6k / 1.0M) the entire time.
For reference, past successful compactions (at heavier load) finished within ~3 min.
I can't tell from the outside whether the backend process is hung or never actually started (UI timer running with no backend work). Both are consistent with what I observed — sharing the raw symptom; logs on your side would disambiguate.

Environment
Claude Code (web), model Opus 4.8 (shown as "256k context"), context-window indicator 388.6k / 1.0M.
Happy to capture more detail / logs if helpful.

MaxLeiter · 4 months ago

Thank you for reporting, the fix has been merged and will be released shortly.

mafuba · 4 months ago

Adding a data point that broadens the scope here: the same fall-through reproduces in a standard claude --remote-control session, not only the externally-triggered web-execution sessions this issue scopes itself to (the description notes "not a standard claude remote-control session"). This overlaps with #29156.

Repro on CLI 2.1.179:

Launch an app-reachable session: claude --remote-control --continue --name <x> --dangerously-skip-permissions
From the Claude mobile or desktop app, type /clear in the chat box and send → it is delivered to the model as a normal user message (echoed in the conversation, and the model replies to it), rather than being intercepted/executed by the CLI. /clear never clears context.
The identical command works correctly when typed in the local terminal TUI for the same session.

The Remote Control docs' Limitations section lists /clear, /compact, /context, etc. as supported from mobile/web on CLI ≥ 2.1.166, so this contradicts the documented behavior. Impact: users who primarily drive sessions from the app can't manage context (/clear, /compact) without attaching a terminal.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.