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
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