[thepigdestroyer]

Problem

Auto-approve permission mode can be reached three ways today:

• CLI flags at launch: --auto, --yolo, --dangerously-skip-permissions
• the permission.mode command in the command palette
• programmatically, via toggle() on the permission context

What is missing is a keybind. Definitions in packages/tui/src/config/keybind.ts has no permission_mode entry, so the command cannot be bound from config, and the only in-session route is opening the palette and picking the entry.

The machinery is already there. context/permission.tsx exposes set() and toggle(), and app.tsx registers a permission.mode palette command with a state-dependent title. This just makes it bindable.

Change

• add permission_mode: keybind("none", "Toggle auto-approve permissions") to Definitions
• map it to the existing permission.mode command in CommandMap
• list permission.mode in appBindingCommands so a layer actually gathers the binding

Default is "none", so nothing changes for anyone who does not opt in.

Three lines, and the third is the one that is easy to miss: a definition plus a CommandMap entry resolves correctly but stays inert unless the command is also in a gathered list. I had this wrong at first and the key silently did nothing.

Verification

• bun run typecheck in packages/tui — clean
• bun test test/keymap.test.tsx test/config.test.tsx — 11 pass

With {"keybinds": {"permission_mode": "ctrl+alt+n"}} in tui.json, resolving through TuiConfig.get() gives:

permission.mode -> [{ desc: "Toggle auto-approve permissions", key: "ctrl+alt+n", cmd: "permission.mode" }]

I also confirmed end to end that toggling this way suppresses prompts, using a permission that evaluates to ask. From the log: asking id=per_… at .714, then the action proceeding at .744 with no prompt rendered.

Notes

Deliberately no default key. Auto-approving permissions is dangerous enough that it should stay opt-in, and I did not want to claim a chord on anyone's behalf.

If you would prefer a keybind naming other than permission_mode, say the word and I will rename.

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found a potential duplicate:

PR #40334: feat(tui): make permission mode keybind configurable
#40334

This PR appears to address the exact same feature as the current PR #42057. Both are about making permission mode bindable via keybinds in the TUI configuration. You should check if #40334 has already been merged or if this is a re-implementation of the same feature.

[thepigdestroyer]

Closing this in favour of #40334, which is the same change and 9 days older. I searched open issues before starting but not open PRs, so I missed it.

For anyone comparing the two: #40334 is functionally identical, including the appBindingCommands entry that the definition needs in order to actually bind. The only difference is the keybind name, app_toggle_auto_approve_permissions there vs permission_mode here, and theirs matches the surrounding app_toggle_* naming better.

I have been running this change locally and can confirm it works: bound to a key, the toggle flips permission.mode mid-session and prompts stop appearing. Details on #40334.