After session reset, assistant doesn’t re-request directory permission on first attempt; bash path is blocked without triggering interactive permission flow

Environment

• WSL2 Ubuntu 24.04 (kernel 6.6.x)
• Default user: yang
• Start directory (cwd) when launching the CLI: /mnt/c/Users/yang
• Tool: Claude Code CLI (reproduced with Opus 4.1 and Sonnet 4)
• Reproduces after model switch or wsl --shutdown (session reset)

Problem summary
After a session reset, the chat context continues but the execution sandbox (and its per-session whitelist) is reset. On the first attempt to access a non-whitelisted path, the assistant often assumes it still has access and sends a bash ls that gets blocked. Crucially, it does not immediately trigger the interactive permission request (e.g., “Add as a working directory”). Only after a subsequent/altered request does the assistant switch to the flow that prompts the user to add the path. This creates a perception gap: the model doesn’t realize the environment requires re-authorization.

Steps to Reproduce
1) Reset: wsl --shutdown, reopen WSL. Ensure pwd = /mnt/c/Users/yang.
2) Ask the assistant in natural language to view /home/yang (e.g., “List /home/yang” / “Check /home/yang”).
3) Observed behavior (first attempt):

• Assistant issues a bash ls /home/yang.
• It’s blocked with:

> For security, Claude Code may only list files in the allowed working directories for this session: '/mnt/c/Users/yang'.

• No interactive prompt to add /home/yang appears.

4) Ask the same again (or phrase slightly differently). Now an interactive prompt may appear:

• “Add /home/yang as a working directory for this session”.
• Choose to add → subsequent ls /home/yang succeeds.

5) Repeat from step 1: behavior repeats (first attempt after reset = no prompt; later attempt = prompt).

Expected behavior

• On the first blocked access after a session reset, the assistant/tooling should recognize the whitelist miss and immediately trigger the interactive permission request (or surface a clear “Add as working directory” affordance). Ideally the router treats this as a deterministic fallback, not dependent on phrasing or retries.

Actual behavior

• First attempt after reset: bash path gets hard-blocked with a custom message and no interactive request UI.
• Only on a subsequent attempt/alternative route does the assistant prompt to add the path, which then works.

Why this matters (UX)

• Chat continuity suggests state is preserved, but execution permissions were reset; the assistant doesn’t reflect that, leading to confusion and extra retries. Users perceive it as the model “thinking it still has permission”.

Suggested improvements
1) Router: on whitelist block, auto-trigger interactive permission request for the specific path; show a clear button in the error UI.
2) Structured errors (e.g., ERR_NOT_WHITELISTED path=/home/yang can_request=true) so the assistant can reliably switch flows on the first attempt.
3) Startup banner after reset: “Permissions reset. Allowed: …”.
4) /status command to list/manage allowed directories; optional per-project defaults (e.g., /home/yang).

Notes / Screenshots

• Before adding: allowed = '/mnt/c/Users/yang'
• After prompt: allowed = '/mnt/c/Users/yang', '/home/yang'
• Screenshots attached: (1) first blocked attempt w/o prompt; (2) later prompt to add directory.

问题概述
会话重置后（例如 wsl --shutdown 或切换模型），聊天上下文还在，但执行沙箱与其“会话级白名单”被清零。首次访问非白名单路径时，助手常常“以为自己还有权限”，先发出 bash ls，被拦后也没有立刻弹出“加入工作目录”的交互。只有第二次/换个说法后，才出现授权弹窗。用户观感是：模型并没有意识到需要“重新申请权限”。

期望

• 在会话重置后的第一次阻拦上，就能自动触发交互式授权（或在错误 UI 中提供明显的“加入白名单”入口），而不是要靠用户重复/改述来触发。

改进建议

• 见英文部分的 1–4 条（自动降级、结构化错误、启动提示、/status 管理）。