feat(web): setting to keep the terminal from taking focus automatically#8372

🟡 Medium components/ThreadTerminalDrawer.tsx:949

Disabling terminalAutoFocus does not prevent a queued terminal.focus() callback from moving focus into the terminal. Both the setup-time callback and the first-session-data callback check shouldAutoFocus only when scheduling and are never cancelled; retain their frame handles and cancel them in cleanup, or re-check the current preference in the callback.

✅ Resolved in 5823e3ed8e0e11c21d61f8b4d27de1a60d36c919

Fixed in 5823e3e. Focus grants now go through an effect event (focusTerminalIfPermitted) that re-checks permission at frame time, so a queued callback can no longer act on a stale grant; the setup-time frame is additionally cancelled via setupCleanups. The first-output frame deliberately has no cancel-on-cleanup: that effect re-runs on every buffer update, and cancelling there would drop a legitimate first-output focus when a second write lands within the same frame - the frame-time check covers the staleness instead.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

components/ThreadTerminalDrawer.tsx:957

focusRequestId is not only an "automatic" focus channel: ChatView bumps it for explicit user actions — activateTerminal / activatePanelTerminal (terminal tab click), createNewTerminal, splitTerminal, closeTerminal — in addition to the drawer becoming visible. Gating this effect on terminalAutoFocus therefore also drops focus for those deliberate interactions, which is wider than the setting's own description ("the terminal only takes focus when you click it").

Concretely, with the setting off and the drawer in single-terminal mode: pressing the new-terminal or close-terminal keybinding unmounts the currently focused viewport (only the active terminal renders in the non-split branch), and no replacement focus is applied, so focus falls to document.body and the user's next keystrokes go nowhere until they click the pane. Same for activating another terminal from the tab list.

Suggest keeping the explicit-request path on autoFocus and gating only the automatic paths (mount-time focus at the surface creation and the first-output focus in the effect above), and splitting the focus-request channel in ChatView so the open/reveal bumps (visible ? 1 : 0, the terminal-open effect) are gated by the setting while action-driven bumps stay ungated. Fix spans this file and ChatView.tsx, so no inline diff.

No longer relevant as of 5823e3ed8e0e11c21d61f8b4d27de1a60d36c919

Fixed in 5823e3e, following the suggested split: the focusRequestId effect is back on plain autoFocus, and the reveal sources in ChatView (the drawer-open bump and the wrapper's visible term) are the gated ones, so create/split/close/tab-activation always focus. Two holes the split alone would have left are also closed: (1) the swap-to-0 for inactive threads made the id jump on activation, which reads as an explicit request - the id is now passed unconditionally and hidden drawers bail out via visibility-gated autoFocus; (2) in the single-terminal view, create/close/activate remounts the viewport in the same render as the bump, so the new viewport's request effect can never see the change - a mount-captured pending flag carries the request across the remount and is consumed by the first focus it grants.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

Auto-focus races with settings hydration

Medium Severity

The setup-time terminal.focus() call captures shouldAutoFocus when the effect starts, and that effect intentionally never re-runs. Client settings hydrate asynchronously from the schema default (true), the same race this file already handles for fonts with a ref. A persisted terminalAutoFocus of false is therefore ignored if Ghostty finishes loading after hydration, so the terminal still steals keyboard focus on first mount — including app restore of a thread whose terminal is already open.

^{Reviewed by Cursor Bugbot for commit f1c443eb979955f1f0b12a84a68dcbf623fac396. Configure here.}

Fixed in 5823e3e using the same live-value pattern as terminalFontRef: the focus callback is an effect event that reads the setting at frame time, so a persisted false that hydrates after mount is honored even when Ghostty finishes loading later, and mid-flight toggles win over the captured render.

Setting bit spoofs explicit focus requests

Medium Severity

The drawer encodes terminalAutoFocus into the composite focusRequestId, while TerminalViewport treats any id change as an explicit request and calls terminal.focus() without consulting the setting. Client settings start as the schema default (true) and hydrate asynchronously, so a stored false changes the id after the Ghostty surface exists and refocuses the terminal. That undoes auto-focus opt-out on reload for the users this setting is for.

^{Reviewed by Cursor Bugbot for commit 5823e3ed8e0e11c21d61f8b4d27de1a60d36c919. Configure here.}

Fixed in c73f8be. The setting (and visibility) are no longer encoded into the composite focus-request id at all - the id now carries only explicit, action-driven requests, so a hydrating or toggling preference changes no id and cannot be spoofed into a request. Reveal focus (thread activation, drawer open) moved into the viewport as a hidden-to-visible transition effect whose grant goes through the same frame-time permission check as the other automatic paths.

components/ThreadTerminalDrawer.tsx:557

The mount-time grant outlives the mount it was captured for. mountFocusPendingRef is only cleared when it actually grants a focus, and mountFocusPending is passed to every viewport mounted on a request render — including split panes that are not the request target (autoFocus={visible && terminalId === resolvedActiveTerminalId}). Those panes keep mountFocusPendingRef.current === true indefinitely, so a later automatic path (the visible reveal effect or the first-output frame, once that pane becomes the active one without a new request — e.g. the active pane's session exits while the drawer is hidden, so bumpFocusRequestId is skipped) will call terminal.focus() even with terminalAutoFocus off, which is exactly what the setting promises not to do.

Since the grant exists only to cover "surface not ready yet at mount", it can be retired as soon as the mount-time focus attempt runs:

No longer relevant as of 8f49ff3bb13fbadf0ed7f307c0b6231cc81df62d

Fixed in 8f49ff3, applying the suggestion as-is. You are right that the grant's lifetime was wrong: it exists only to cover "surface not ready at mount", so it is now retired at the first ready frame whether or not it granted - a non-target split pane forfeits it there (autoFocus false), and no later reveal can spend it with the setting off. The first-output path does not need the grant: the surface-ready frame fires before output and already handles the mount-request case.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.