Orphaned  permission.requested  event replays on every session resume, causing repeated directory-access prompts that can't be dismissed

Describe the bug

Summary:
A long-lived, repeatedly-resumed CLI session is showing a recurring "Allow directory access" prompt at startup, every time, for over a week. The prompt references a path ( ../Zscaler-....zip ) from a bash command that was run and completed 10 days prior. Approving the prompt has no effect — it reappears on the next resume.

Root cause (found via session logs/events.jsonl):

• On 2026-08-02, a  permission.requested  event was logged for a shell command ( unzip ../Zscaler-....zip ) in session  5ee3e3d6-afd7-4534-b4a9-ad665f1d8e5e .
• The associated tool call completed successfully ( tool.execution_complete , success), but no corresponding  permission.completed  event was ever written for that  requestId .
• On every subsequent resume of this same session, the runtime appears to replay/re-surface this orphaned, still-"pending" permission request to the user.
• When the user answers, the log shows:  Ignoring permission response for already-resolved tool call '' (request '')  — confirming the runtime treats the underlying tool call as already resolved, but never clears the dangling permission-request state, so it keeps re-prompting on a loop that can never be satisfied.

Impact: Users on long-lived resumed sessions get a spurious, unresolvable permission prompt on every startup indefinitely, referencing stale/irrelevant paths from old completed commands, with no way to dismiss it via the answer options offered.

Suggested fix: On session resume, either (a) skip replaying  permission.requested  events whose tool call has already reached a terminal state (success/failure), or (b) write a  permission.completed  event immediately once a tool call completes, regardless of whether the permission response was captured in time.

Workaround used: Starting a new session instead of resuming the affected one.

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

从受影响会话的 events.jsonl 开始，跟踪在恢复会话期间如何重放 permission.requested 事件。将孤立请求与已完成的 tool.execution_complete 事件以及缺失的 permission.completed 事件进行比较。完成的标准是：已完成的工具调用不再导致过时的权限提示在之后的会话恢复中重新出现。