bug(driver-docker): token file not cleaned up when container is already gone with no pending record #3041

Activity

1. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 31, 2026
2. letv1nnn commented on Sep 8, 2026

   

   letv1nnn

   on Sep 8, 2026

   Contributor

   More actions

   📋 triage-agent

   Triage Assessment

   Classification: validated-bug

   Summary

   Confirmed by direct code read. High confidence.

   Investigation

   delete_sandbox_inner in crates/openshell-driver-docker/src/lib.rs (~line 1042-1105): when find_managed_container_summary returns None (no live container) and remove_pending_sandbox also returns None (no in-memory pending record), execution falls through to return Ok(false); at line 1081 with no call to any token-cleanup function. Every other exit path in this function (live container found, or pending record present with container gone) calls cleanup_sandbox_token_file / cleanup_sandbox_token_file_for_delete before returning. cleanup_sandbox_token_file_by_id(sandbox_id, config) (line 2695) already supports id-only cleanup with no dependency on a PendingSandboxRecord, so the fix is a straightforward added call before the Ok(false) return — no new plumbing required. Related to #2352 (closed), which fixed the server-side gap so out-of-band container removal now reaches DeleteSandbox at all; this issue is the one remaining Docker-side branch that isn't idempotent-complete for that fix to fully close the leak.

   Impact Signals

   • Affected users/scope: Docker-driver deployments only; triggered when a container is removed out-of-band (e.g. docker rm -f) after the in-memory pending record has expired or the gateway has restarted.
   • Regression: No — this branch predates bug(driver-podman): per-sandbox secrets and volumes are orphaned when a container disappears without DeleteSandbox #2352 and was never covered.
   • Workaround: None found; token file persists on disk until manual cleanup.
   • Evidence quality: High — exact code path and missing call confirmed by reading the function directly; no reproduction run needed given the code is unambiguous.

   Human Decision Required

   Decide whether OpenShell should address this issue. If yes, apply
   state:accepted, associate it with a roadmap item, or do both, and decide
   whether the work remains human-owned. Either action records acceptance;
   roadmap placement additionally records sequencing.
   To queue investigation or planning for an unattended agent, also apply
   agent:plan-requested. You can instead directly ask an agent to use
   create-spike or build-from-issue on this issue; the agent will warn about
   missing expected workflow labels and continue without changing them. If no,
   close it as not planned and record the rationale.

   Note: I do not have permission to update labels on this repo (state:triage-needed → state:validated, add area:compute). A maintainer needs to apply these manually.
3. letv1nnn commented on Sep 8, 2026

   

   letv1nnn

   on Sep 8, 2026

   Contributor

   More actions

   Hey @politerealism, I'd like to take this one.
4. politerealism commented on Sep 8, 2026

   

   politerealism

   on Sep 8, 2026

   ContributorAuthor

   More actions

   Sounds good tome!

   👍React with 👍1Reacted by Artem Lytvyn
5. johntmyers

   closed this as completedin #3220on Sep 10, 2026
6. purp

   removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Oct 1, 2026