{"content":"[Dev Journal] fix: stop DSH worker sessions hanging forever on delete confirmations (fe000ece, fix/dsh-integration-issues)\n\nProblem: background worker sessions (running acceptEdits, no human watching) hung permanently on `rm -rf` cleanup steps. evaluateDshToolPolicy forced decision:'ask' for EVERY delete, and the DSH approval bridge registered pendingPermissions with no timeout at all — the 60s permission timeout only existed on the local Claude path — while the DSH stall watchdog deliberately extends through a pending permission. Net: a confirmation nobody could ever answer, with no exit.\n\nRoot-cause twist: the code comment claimed delete-ask parity with the Claude path 'under full trust', but canUseTool actually SKIPS the delete-safety question under acceptEdits/bypassPermissions. The unconditional ask was the regression introduced by the DSH kernel switch.\n\nFix (two layers):\n1. Delete confirmation fires only under 'default' permission mode (Claude-path parity restored; acceptEdits/bypassPermissions allow; a missing active session fails closed to ask).\n2. DSH onApprovalRequest now routes through the shared waitForPermissionResponse: 60s auto-reject + abort wiring + pendingPermission cleanup, so an unanswered approval (background worker, or a session switched away in the UI) returns the tool call instead of wedging the turn forever.\n\nVerified: new coworkDshDeletePolicy matrix test (mode × delete commands) + full DSH suite green.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}