Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] /status footer hint shows "Esc to cancel" even when Escape is unbound in keybindings.json [1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56309•Fetched 2026-05-06 06:31:31
View on GitHub
Comments
1
Participants
1
Timeline
5
Reactions
0
Author
MateoGreilMateoGreil
Participants
MateoGreilMateoGreil
Timeline (top)
labeled ×4commented ×1

Root Cause

I rebound cancel away from escape (because I run Claude Code inside an nvim terminal where Esc has special meaning) by setting "escape": null in every relevant context. The actual key behavior is correctly disabled — pressing Esc no longer cancels in Chat, Confirmation, Help, etc. — but the /status modal still tells me to press Esc.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • I am using the latest version of Claude Code

What's Wrong?

The footer hint at the bottom of the /status modal is hardcoded to display "Esc to cancel", regardless of the user's ~/.claude/keybindings.json configuration.

I rebound cancel away from escape (because I run Claude Code inside an nvim terminal where Esc has special meaning) by setting "escape": null in every relevant context. The actual key behavior is correctly disabled — pressing Esc no longer cancels in Chat, Confirmation, Help, etc. — but the /status modal still tells me to press Esc.

So the UI hint and the actual key binding disagree. A new user following the hint would press a key that does nothing.

What Should Happen?

The footer hint should reflect the effective binding for the relevant cancel/dismiss action — e.g. read it from the resolved keybinding map. If the user has unbound `escape` and bound `ctrl+c` instead, the hint should say "Ctrl+C to cancel" (or be hidden if no binding is set).

This likely affects more than just `/status` — any modal that prints a hardcoded "Esc to ..." label has the same problem (e.g. attachments, diff dialog, help overlay).

Steps to Reproduce

  1. Create `~/.claude/keybindings.json` with: ```json { "$schema": "https://www.schemastore.org/claude-code-keybindings.json", "bindings": [ { "context": "Select", "bindings": { "escape": null, "ctrl+c": "select:cancel" } } ] } ```
  2. Restart Claude Code.
  3. Run `/status`.
  4. Observe the footer at the bottom of the modal.

Expected: footer says "Ctrl+C to cancel" (or whatever is currently bound). Actual: footer says "Esc to cancel".

Additional Notes

  • There is no `Status` context listed in the available contexts, so users have no way to override the binding for this modal specifically.
  • Pressing Esc in `/status` does still close the modal — suggesting the modal's escape handler is hardcoded and bypasses `keybindings.json` entirely. If that's correct, the bug is twofold: (a) the binding override isn't honored for this modal, and (b) the displayed hint can't be customized either.

Claude Code Version

2.1.128

Platform

Anthropic API (Claude Team account)

Operating System

Linux (Ubuntu, kernel 6.17)

Terminal/Shell

Ghostty + zsh

Is this a regression?

Not sure — the keybindings system is relatively new, so this may have always been the case.

extent analysis

TL;DR

The footer hint in the /status modal should be updated to reflect the effective key binding for cancel/dismiss action, rather than being hardcoded to "Esc to cancel".

Guidance

  • Verify that the keybindings.json file is correctly formatted and loaded by Claude Code.
  • Check if there are any other modals with hardcoded "Esc to ..." labels that may be affected by this issue.
  • Consider adding a Status context to the available contexts to allow users to override the binding for this modal specifically.
  • Investigate why pressing Esc in /status still closes the modal, despite the binding being overridden in keybindings.json.

Example

No code snippet is provided as the issue is more related to configuration and key bindings.

Notes

The issue may not be limited to the /status modal, and other modals with hardcoded labels may be affected. The fact that pressing Esc still closes the modal suggests that the modal's escape handler may be hardcoded and bypasses keybindings.json.

Recommendation

Apply workaround: update the footer hint in the /status modal to reflect the effective key binding for cancel/dismiss action, or hide the hint if no binding is set. This will ensure that the UI hint and actual key behavior are consistent.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] /status footer hint shows "Esc to cancel" even when Escape is unbound in keybindings.json [1 comments, 1 participants]