fix(cli): TUI /new leaks the previous session's Full access (bypass) into the fresh session #3020

What happened

In the TUI (maka), elevating a session to Full access (bypass) and then starting a fresh session with /new silently carries Full access into the new session:

1. The status line keeps showing Full access after /new.
2. The next prompt actually creates the new session with permissionMode: 'bypass' — tools then run with direct file/network access in a brand-new session the user never elevated.

Expected: a fresh session starts at the default mode (Auto / ask), and Full access is an explicit per-session opt-in. That is the model every other surface follows:

• TUI cold start hard-codes permissionMode: 'ask' (packages/cli/src/runtime-host-tui-command.ts, runtime-host-tui-context.ts)
• maka run defaults to ask unless --yolo is passed explicitly (packages/cli/src/run-command-core.ts)
• Desktop creates new chats with the settings-backed chatDefaults.permissionMode (fallback ask), never the previously viewed session's elevated mode (apps/desktop/src/main/create-session-input.ts)

startNewSession() even documents this intent — "A fresh session is not bound by the previous one's boundary" — but it only clears #activeBoundaryDisplayMode, not #permissionMode, and #createSession passes this.#permissionMode to session.create, so the elevation leaks anyway.

How to reproduce

1. maka in any project; send a prompt to create session A.
2. Open the permission picker and switch to Full access (confirm the prompt).
3. Type /new.
4. Send any prompt.

Observe: the status line shows Full access after /new, and the newly created session runs with full access (no sandbox boundary prompt, direct file/network reach).

Verified against source with the real TUI driver path (driver.setPermissionMode('bypass') → startNewSession() → preparePrompt()): getPermissionMode() after /new returns bypass, and the resulting session.create request carries permissionMode: 'bypass'.

Root cause: packages/cli/src/runtime-host-session-driver.ts — startNewSession() resets #sessionId and #activeBoundaryDisplayMode but leaves #permissionMode untouched.

Environment

• Maka version or commit: 2f76c31 (main)
• OS and version: Linux
• Surface: TUI
• Node.js version, if running from source: v26.3.0

Logs, screenshots, or additional context

Reproduction output (script driving the compiled driver the same way the TUI does):

session A created with permissionMode: ask
after setPermissionMode(bypass), getPermissionMode(): bypass
after /new (startNewSession), getPermissionMode(): bypass   ← should be ask
session B created with permissionMode: bypass               ← should be ask

Suggested fix: have startNewSession() reset #permissionMode to the driver's construction-time default (what the TUI passed in, ask today), so a per-session elevation never leaks into a fresh session. Users who want Full access in the new session can re-enable it explicitly before the first prompt — setPermissionMode already supports the no-active-session path for exactly that.

This issue was investigated and prepared with AI assistance (Maka agent); a human contributor reviewed the analysis and reproduction before submission.