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

Commencez par le events.jsonl de la session concernée et suivez la manière dont les événements permission.requested sont rejoués lors de la reprise de la session. Comparez la demande orpheline avec l’événement tool.execution_complete terminé et avec l’événement permission.completed manquant. Le travail est terminé lorsqu’un appel d’outil terminé ne provoque plus la réapparition de l’invite d’autorisation obsolète lors des reprises ultérieures.