feat(chat): Claude permission-mode selector with gated bypass

[pjdoland]

Summary

Adds the Claude permission-mode selector requested in #359: a compact icon button next to the chat send button (Claude mode only) that opens a menu of Default / Accept Edits / Plan. The selected mode rides each request and is applied to the SDK client immediately. This replaces the /enter-plan-mode and /exit-plan-mode slash commands, which are kept working as hidden aliases for one release but no longer autocomplete. "Bypass Permissions", which removes NBI's tool-call confirmation entirely, is offered only behind a new admin policy and an explicit per-session arm step.

Solution

Selector + mode application. The frontend sends a permissionMode field on each chat request. Plan approval, the hidden aliases, and the per-request mode all route through one apply_permission_mode helper in claude.py, so the tracked mode and a new claude-permission-mode-change websocket notification stay in sync with what the SDK was actually told. The selector follows that notification (plan approval resetting to default, etc.).

Bypass is gated as a distinct armed mode, since in bypass the SDK skips can_use_tool and the CLI's built-in Bash/Write/Edit run unconfirmed as the Jupyter user:

• New claude_bypass_permissions policy (NBI_CLAUDE_BYPASS_PERMISSIONS_POLICY) defaulting to force-off, the only policy whose default isn't user-choice. It threads through the existing seven-place policy framework. user-choice exposes the option; the user still arms it per session through a confirm-to-arm step, and it never survives a new session or a fresh SDK client.
• The mode is clamped server-side at the websocket boundary (resolve_permission_mode), so a hand-rolled request can't escalate past what the selector offers. Unknown modes, and the confirmation-skipping dontAsk/auto, fail closed to default.
• NBI defers to Claude Code's enterprise managed settings as defense in depth: permissions.disableBypassPermissionsMode refuses bypass regardless of the NBI policy (a corrupt managed-settings file fails closed), and permissions.defaultMode seeds the selector's starting mode (bypass excepted, so it never auto-arms).

UX / a11y. The armed state shows a red warning glyph plus an aria-label (not color alone, WCAG 1.4.1). The menu has roving Arrow-key focus, Escape to close, focus-move to the checked item on open, and focus restoration to the trigger. The confirm dialog is a focus-managed alertdialog with Escape-to-cancel.

Testing

• tests/test_permission_modes.py (32): the clamp (fail-closed on unknown/dontAsk/None/bypass-when-forbidden), managed-settings reads (corrupt-fails-closed, defaultMode), apply_permission_mode tracking/notify, reset semantics, and the policy-response wiring.
• tests/test_websocket_handler_integration.py (+6): the security-critical boundary, driving real on_message and asserting the clamped permission_mode on the resulting ChatRequest (bypass forbidden/allowed, unknown, missing, class-default-fails-closed).
• tests/ts/permission-mode-select.test.tsx (13): menu listing by policy, immediate switching, confirm-to-arm, cancel, Escape, arrow-key roving, focus-move, armed aria-label, and the policy-revoked-but-active case.
• A suite-wide conftest fixture points the managed-settings probe at an empty path so capability/policy tests aren't coupled to the host.
• Full verification green: pytest 1211 (+57 claude_client), tsc --noEmit, lint:check, jest 365.
• Live-verified in JupyterLab across both policy states: the compact icon-button menu (24x24, sparkle preserved), force-off hiding bypass, the confirm-to-arm flow with the red armed indicator, plan mode gating an agent turn until approval, Accept Edits letting the agent edit without confirmation, the hidden aliases still working while dropped from autocomplete, and the mode-change notification reaching the selector. Zero console errors.

Risks / follow-ups

• The selector is Claude-mode only; non-Claude modes are unchanged.
• Bypass is per-session and re-armed each time; there is intentionally no "remember bypass" persistence.
• Screenshots of the compact footer and armed state can be added to this description on request (gh can't upload images, so they need a drag-drop).

Closes #359

[mbektas]

@pjdoland this looks great overall. some issues I noticed.

1. There isnt good indication of selected mode. should we instead use an explicit dropdown or icons / colors as indicator?
2. I noticed an issue with the activation / reset of the selected tool. it is shown in the capture. selection updates with a delay.

[mbektas]

on my machine I am getting this error in Bypass Permissions mode:

Error communicating with Claude agent: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions

[mbektas]

can we make these buttons small?

[pjdoland]

Thanks Mehmet! Both points in this comment are addressed.

1. There isnt good indication of selected mode. should we instead use an explicit dropdown or icons / colors as indicator?

Went with the icons route you suggested. Each mode now has its own Codicon glyph on the footer button, echoed next to the label in the menu so the mapping is learnable:

• Default: shield
• Accept Edits: filled check-circle
• Plan: checklist
• Bypass Permissions: red warning triangle (kept as the persistent, non-color-only armed indicator)

(I first tried a text label, but it didn't fit the narrow input footer, it overlapped the mode toggle and the send button, so the per-mode icons are the better fit there.)

2. I noticed an issue with the activation / reset of the selected tool ... selection updates with a delay.

Root cause was the backend emitting a permission-mode reset on every (re)connect (the background connect completing, a skills/config reload), which clobbered your selection back to Default a moment after you picked it. The reset notification now carries a reset flag: a reset only retires Bypass and preserves an explicit non-bypass selection, so the selector updates immediately and a reconnect no longer snaps it back.

[pjdoland]

on my machine I am getting this error in Bypass Permissions mode: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions

Fixed. The CLI refuses set_permission_mode("bypassPermissions") unless the session was launched with --dangerously-skip-permissions. I tried launching with that flag, but live testing showed it disables every permission prompt for the whole session (Default / Accept Edits / Plan silently ran Write/Bash with no confirmation), and it can't be scoped to just the Bypass turns.

So Bypass is now realized in NBI's own permission handler rather than the CLI's bypass mode: when the selector is in Bypass the handler auto-allows every tool, and the CLI stays in default. No launch flag, the other modes still gate normally, and the error is gone. Verified live: Default/Accept Edits/Plan prompt for confirmation, Bypass runs without prompting, and switching back re-gates.

Related hardening while in here: Bypass now also correctly drops on a New chat session / /clear (previously the tracked mode could stay armed into the "fresh" session), so a new session always starts gated.

[pjdoland]

can we make these buttons small?

Done. The confirm-to-arm Cancel / Bypass buttons are now compact (dropped the full jp-Dialog-button sizing), with a 24px min-height floor so they stay a usable target. While testing this I also moved the confirm popover into a portal so it can no longer run off-screen in a narrow left-docked sidebar, and trapped focus within it (it is a security-gating dialog).