SDK permission callback binding lost in headless mode after reconnections

[PureWeen]

Problem

The copilot SDK's internal permission system returns denied-no-approval-rule-and-could-not-request-from-user when the permission callback binding is lost in headless persistent mode. PolyPilot correctly sets AutoApprovePermissions on all session configs, but the headless server loses the binding after reconnections.

Symptoms

• Tool executions return "Permission denied and could not request permission from user"
• Intermittent — happens after the persistent server has been running for a while
• Pattern: 2-4 consecutive denials, sometimes with an OK interspersed

Current workaround

• PR Session resilience: heartbeat timer, permission auto-recovery, activity-aware watchdog #285 adds sliding window detection (3 of last 5 tool results denied)
• Auto-recovery: dispose broken session, resume with fresh OnPermissionRequest callback, resend last prompt
• Max 2 recovery attempts per session before giving up

Root cause

SDK source at /opt/homebrew/lib/node_modules/@github/copilot/sdk/index.js:

• pW() handles permission results, Fmr() handles the no-approval-rule case
• The permission callback registered via OnPermissionRequest appears to be lost server-side

Desired fix

Fix the SDK to maintain the permission callback binding across reconnections in headless mode. This would eliminate the need for client-side detection and recovery.

References

• PR Session resilience: heartbeat timer, permission auto-recovery, activity-aware watchdog #285 (permission detection + auto-recovery)
• String matching on 'Permission denied' is fragile — SDK should expose error codes

[PureWeen]

Update: PolyPilot-side detection + recovery now works (PR #361)

What was broken in PolyPilot

The permission denial detection was silently broken since inception. ToolExecutionCompleteDataError.ToString() returns the .NET type name ("GitHub.Copilot.SDK.ToolExecutionCompleteDataError"), NOT the error message. The sliding window detection was checking Error.ToString() for "Permission denied" — which never matched. The entire recovery pipeline (TryRecoverPermissionAsync) was dead code.

Evidence: Session 1961a585 had 28 consecutive permission denials with zero [PERMISSION-RECOVER] entries in diagnostics — recovery never triggered.

Fix in PR #361

• ExtractErrorMessage() now reads Error.Message and Error.Code via reflection
• Sliding window detection now correctly fires at 3/5 denials
• TryRecoverPermissionAsync disposes the broken session, calls ResumeSessionAsync with fresh AutoApprovePermissions, and resends the last prompt
• Added [PERMISSION-DENY] diagnostic logging for every denial event (black box recorder)
• Tool history now shows the actual error message (was blank for denied tools)
• 6 new tests for ExtractErrorMessage

Upstream SDK bug still exists

The root cause is in the SDK: the OnPermissionRequest callback binding is lost after reconnections in headless persistent mode. PolyPilot correctly sets AutoApprovePermissions on every session create/resume, but the server-side binding silently drops. This is not something PolyPilot can prevent — only detect and recover from.

Recommendation

Keep this issue open to track the upstream SDK bug. The PolyPilot mitigation reduces impact from "session-killing failure" to "~4-second recovery blip", but the SDK should not be losing the callback.

[PureWeen]

Update: Root cause identified + SDK fix ready

Precise root cause

The bug is in the SDK's Session.DisposeAsync() and Client session map management:

1. DisposeAsync() nulls _permissionHandler but never removes the session from Client._sessions — the disposed session stays in the map as a zombie
2. The CLI broadcasts permission.requested to ALL sessions via HandleBroadcastEventAsync
3. The disposed session receives the broadcast, finds _permissionHandler == null, and silently returns (assuming "another client will handle it")
4. In single-client headless mode, there IS no other client → CLI hangs forever waiting for a permission decision

This is deterministic, not intermittent: dispose session A → create session B → session B's permission requests get swallowed by the zombie session A.

SDK fix: PureWeen/copilot-sdk#4

Three-part fix across .NET, Node.js, and Go SDKs:

1. Disposed guard in DispatchEvent — prevents events from reaching disposed sessions
2. OnDisposed callback — invoked at start of DisposeAsync, wired in Client to remove from _sessions map
3. Explicit denial — when _permissionHandler is null, sends DeniedCouldNotRequestFromUser via RPC instead of silently returning

Includes an E2E regression test: create session A → dispose → create session B → trigger permission → assert B handles it.

Status

• Fix is code-reviewed (4 parallel reviews, all platforms clean)
• Ready for upstream PR when desired
• PolyPilot workaround from PR fix: watchdog Case B checks events.jsonl freshness before completing #361 remains as defense-in-depth

[PureWeen]

Correction to Root Cause Analysis

After running E2E tests against the SDK fix (both with and without the patch), we discovered our earlier root cause description was inaccurate:

What we said (incorrect): Disposed sessions intercept broadcast permission.requested events meant for other sessions, causing the CLI to hang.

What actually happens: Permission events are always per-session — the CLI sends session.event(sessionId=B, PermissionRequestedEvent) targeting the specific session. A disposed session A cannot intercept events meant for session B.

What the SDK fix actually provides:

• Memory leak fix: DisposeAsync() does not remove the session from Client._sessions. Over time, disposed session objects accumulate in the map. The OnDisposed callback fixes this.
• Defensive disposed guard: Prevents events from being dispatched to a session mid-disposal (race window protection).

What it does NOT fix:

• Permission routing hangs — these were never caused by disposed sessions intercepting broadcasts.

The upstream PR (github/copilot-sdk#1130) is being updated to reflect the accurate scope. PolyPilot's existing auto-recovery workaround (PR #361) addresses whatever the actual permission hang root cause is — that remains a separate investigation.

Updated assessment: Issue #300 as originally described (permission callback lost due to disposal) is partially valid — the callback IS lost and the session IS leaked — but the impact is memory leak, not permission routing failure.

[PureWeen]

Closing — the original hypothesis (disposed sessions intercepting broadcast permission events) was disproven. Permission events are per-session by sessionId, not broadcast. The workaround (PR #361: detect denial patterns → reconnect → resend) handles the symptom effectively. Root cause remains unknown but not worth further investigation.