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イベントと比較します。完了条件は、完了したツール呼び出しによって、後の再開時に古い権限プロンプトが再表示されなくなることです。