What happens
In tab mode — the default, and the reason flue lives in a browser at all — a handful of chords are taken by the browser before the page sees them, and no amount of preventDefault gets them back.
The one that hurts is Ctrl+W: delete-word-backwards in every shell and every agent prompt, and "close this tab" in every browser. Somebody trimming a path loses the session instead. The rest of the family is Ctrl+T, Ctrl+N, Ctrl+Shift+T/N/W, Ctrl+Tab and Ctrl+1–9; on macOS, Cmd+W/T/N/Q and Cmd+`.
What already exists
Focus mode (web/src/lib/keyboard.ts) is the answer for this: fullscreen plus navigator.keyboard.lock(), after which the terminal receives every key, with Chromium's hold-Esc as the way out. It is reachable on Ctrl+Shift+Enter and named in the connecting pill.
Two things limit it. It is Chromium-only — the Keyboard Lock API exists nowhere else, and createKeyboardModes treats that as "tab mode is the only mode" rather than as an error. And it is all-or-nothing: fullscreen is a large price for getting one chord back, and the pill that teaches the shortcut is gone in a hundred milliseconds on a local daemon.
Worth considering
- Making focus mode discoverable somewhere that is not a pill with a hundred-millisecond life — the control strip has room, and it would also say what mode the terminal is in.
- Saying something honest in Firefox and Safari, where the chord does nothing at all today.
- Whether a remap is worth offering for Ctrl+W specifically. Chrome's beforeunload cannot cancel a tab close, so there is no way to intercept it — but a rebindable "delete word" (Ctrl+Backspace is free, and is what several browser terminals use) would give the motion back without asking for fullscreen.
Not a bug in the sense that anything is broken — the platform is what it is — but it is the first thing a shell user trips over, and right now the app says nothing about it.
What happens
In tab mode — the default, and the reason flue lives in a browser at all — a handful of chords are taken by the browser before the page sees them, and no amount of
preventDefaultgets them back.The one that hurts is Ctrl+W: delete-word-backwards in every shell and every agent prompt, and "close this tab" in every browser. Somebody trimming a path loses the session instead. The rest of the family is Ctrl+T, Ctrl+N, Ctrl+Shift+T/N/W, Ctrl+Tab and Ctrl+1–9; on macOS, Cmd+W/T/N/Q and Cmd+`.
What already exists
Focus mode (
web/src/lib/keyboard.ts) is the answer for this: fullscreen plusnavigator.keyboard.lock(), after which the terminal receives every key, with Chromium's hold-Esc as the way out. It is reachable on Ctrl+Shift+Enter and named in the connecting pill.Two things limit it. It is Chromium-only — the Keyboard Lock API exists nowhere else, and
createKeyboardModestreats that as "tab mode is the only mode" rather than as an error. And it is all-or-nothing: fullscreen is a large price for getting one chord back, and the pill that teaches the shortcut is gone in a hundred milliseconds on a local daemon.Worth considering
Not a bug in the sense that anything is broken — the platform is what it is — but it is the first thing a shell user trips over, and right now the app says nothing about it.