[Bug]: Can't change Keybindings #11448

Activity

1. Ar-Kareem

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 12, 2026
2. juliusmarminge commented on Sep 12, 2026

   

   juliusmarminge

   on Sep 12, 2026

   Member

   More actions

   Triage

   Confirmed as a real settings-write bug, not a duplicate of #11108 (that one is about sibling drafts resetting after a successful save).

   What we think is going on

   Settings → Keybindings keeps edits in local React draft state. Save is supposed to persist via WebSocket RPC server.upsertKeybinding to each connected environment in the current settings scope (KeybindingsSettings.tsx), then the server writes keybindings.json.

   Two things line up with “I click Save forever and nothing happens”:

   1. Silent no-op when there is no connected write target. saveKeybinding does if (!primaryEnvironment) return with no toast. primaryEnvironment here is the first connected environment in scope, not merely “a machine I can see.” If that list is empty, the handler exits, no RPC is sent, and the dirty Save button stays. The page still renders built-in defaults (DEFAULT_RESOLVED_KEYBINDINGS), so it looks fully editable.

      Other server settings already refuse this case (planScopedSettingsPatch / inert “Reconnect…”). Keybinding rows do not. The settings shell only blocks a disconnected environment scope; All / project / checkout still show the editor.

      On app.t3.codes this is especially easy to hit: the hosted app has no PrimaryConnectionTarget (every device is a remote pair). That is the same class of “reads look like defaults, writes vanish” as fix(web): point settings panels at a connected device #5692 / feat(web): settings only show up where they can actually be saved #5832.

   2. No HTTP request is expected even when Save works. The write is a frame on the existing WebSocket, not fetch/XHR. An empty Network log (Fetch/XHR) does not prove the click never ran. What does prove the write did not apply is the Save button remaining dirty and the lack of an error toast.

   The _cfuvid cookie messages are unrelated.

   Surfaces

   • Web + desktop share this editor. Mobile has no keybindings settings page.
   • Entry point: Settings → Keybindings (and the Open keybindings.json control).

   Workaround

   Edit the environment’s keybindings.json directly (~/.t3/userdata/keybindings.json by default; see the Keybindings user doc). That path still works if the UI save is a no-op.

   Suggested fix

   In KeybindingsSettings, never silent-return on Save/Remove. If connectedEnvironments.length === 0, disable Save and show the same reconnect / hosted-app copy other server settings use. After that, re-check Firefox on app.t3.codes while a remote environment is actually connected (WS frames, not HTTP). If Save still no-ops in that state, next place to look is the capture-input onBlur re-render vs the Base UI Save button eating the click.

   Related

   • [Bug]: Saving a keybinding discards other unsaved keybinding edits #11108 / fix(web): preserve unsaved keybinding edits when saving another binding #11109 — different bug (unsaved sibling rows reset when another row saves)
   • fix(web): point settings panels at a connected device #5692 / feat(web): settings only show up where they can actually be saved #5832 — hosted settings writes dropped with no feedback
   • feat(web): keybinding settings as settings rows #8532 — current keybindings settings UI
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 12, 2026
4. t3dotgg commented on Oct 14, 2026

   

   t3dotgg

   on Oct 14, 2026

   Member

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Theo

   Status:

   • feat(auth): separate environment administration permissions #9786 (merged 2026-10-07) fixed the silent no-op. With no environment connected, the keybinding editor is locked and Save cannot be clicked.
   • fix(web): keybindings page says to connect an environment when none is connected #19400 replaces the misleading permission text in that state with "Connect an environment to change keybindings."

   Still unconfirmed: the second cause in the triage, where Save does not save in Firefox while a remote environment is connected. From the code, the Save click should not be lost, but nobody has tested it in a browser. If you still can't save keybindings with an environment connected, please say which browser and connection type you use.