[FEATURE] Support read-only slash commands in AskUserQuestion input
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When Claude uses the AskUserQuestion tool to prompt for input (commonly during Plan Mode), the free-text field accepts any text. If a user types a slash command (e.g., /cost, /help) into that field, the text is submitted as a literal string answer to the question rather than being intercepted as a command.
Observed behavior: Typing /cost into the AskUserQuestion input submits the string "/cost" as the answer. Claude then interprets it as conversational text. The user must dismiss or answer the question, return to the main prompt, and re-enter the command.
Why this matters: The AskUserQuestion input looks and feels like the main prompt. There is no visual indicator that slash commands are unavailable in this context. Users who habitually type /cost or /help discover the difference only after submission.
This is a minor UX inconsistency, not a blocker. The workaround (answer first, then run the command) is straightforward but unintuitive.
Proposed Solution
Minimal scope (recommended): Support a small set of stateless, read-only slash commands within the AskUserQuestion input:
/cost//usage— display session cost/usage info/help— show available commands/exit— exit the session
When the user submits one of these commands, display its output inline, then re-present the same AskUserQuestion prompt so the user can still answer the original question.
Why only stateless commands: Commands like /compact modify conversation history and interact with the tool_use/tool_result message contract. Executing /compact mid-question could leave an orphaned tool_use without a corresponding tool_result, potentially corrupting conversation state. Stateless commands avoid this entirely because they only render local information and do not alter the message stream.
Namespace disambiguation: Text starting with / that does not match a registered command should be passed through as-is (current behavior), preserving the ability to type answers like /api/v2.
Out of scope: Custom skills, user-defined commands, and state-modifying commands (/compact, /clear, /model) — these require deeper architectural consideration.
Alternative Solutions
- Visual hint: Display a note in the AskUserQuestion UI: "Slash commands are not available here. Press Escape to return to the main prompt." Zero-risk, addresses discoverability.
- Escape-to-dismiss: Ensure pressing Escape cleanly returns to the main prompt (where all commands work), sending
[User cancelled]as the tool_result. (Related: #27998 reports AskUserQuestion blocking visibility of Claude's response.)
- Documentation only: Add a note to
/helpoutput clarifying that commands are only available at the main prompt. Lowest effort.
Priority
Low
Feature Category
TUI
Use Case Example
Scenario 1: Checking cost mid-plan
- User is in Plan Mode. Claude presents options via AskUserQuestion: "Which approach would you like?"
- Before deciding, the user wants to check remaining budget: types
/cost. - Current: "/cost" is submitted as the answer. Claude responds with confusion.
- Desired: Cost info is displayed, then the question re-appears.
Scenario 2: Needing help with available commands
- AskUserQuestion prompts the user during a planning session.
- User types
/helpto check available commands. - Current: "/help" becomes the answer text.
- Desired: Help output is shown, question re-appears.
Additional Context
Related issues:
- #18913 — Feature request for async command execution while Claude is busy (same theme: commands should work regardless of UI state)
- #10057 — Slash commands ignored during task execution (closed; same class of problem)
- #16072 — System prompt conflates skills and slash commands (relevant background; this request intentionally excludes skills)
- #27998 — AskUserQuestion popup blocks reading Claude's response (related AskUserQuestion UX)
Note: Claude Code is a closed-source application. The suggestions above are based on observed behavior and may need adjustment based on actual architecture. The "stateless commands only" scope is deliberately conservative to minimize risk.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗