bug(driver-docker): deleting a sandbox can destroy a same-named sandbox in another workspace

[letv1nnn]

User Story

As an operator running multiple workspaces on a single OpenShell gateway with the Docker compute driver, I want deleting a sandbox to affect only that sandbox, so that tenants sharing a gateway cannot destroy each other's running sandboxes by picking the same sandbox name.

Problem Statement

The Docker driver resolves entries in its in-memory pending map with pending_sandbox_matches (crates/openshell-driver-docker/src/lib.rs:2165):

fn pending_sandbox_matches(sandbox: &DriverSandbox, sandbox_id: &str, sandbox_name: &str) -> bool {
    (!sandbox_id.is_empty() && sandbox.id == sandbox_id)
        || (!sandbox_name.is_empty() && sandbox.name == sandbox_name)
}

A record matches on id or name, and workspace is never consulted even though DriverSandbox carries it. The gateway always sends both fields (crates/openshell-server/src/compute/mod.rs:1628), so the name clause can match a record belonging to a different sandbox.

Sandbox names are unique per workspace, not globally — see sqlite_name_unique_scoped_by_workspace in crates/openshell-server/src/persistence/tests.rs:684, which asserts that ("sandbox", "id-1", "shared-name", "alpha") and ("sandbox", "id-2", "shared-name", "beta") coexist as separate records. The Docker driver has a single flat config.sandbox_namespace, so every workspace's sandboxes share one pending map.

Given sandbox A (sbx-A, name demo, workspace alpha) whose provisioning already completed and whose container was later removed out-of-band, and sandbox B (sbx-B, name demo, workspace beta) currently provisioning, delete_sandbox_inner("sbx-A", "demo") (:1065) does the following:

1. :1070 remove_pending_sandbox pops B's record — A is no longer in the map, and B matches on the name clause.
2. :1074 task.abort() kills B's in-flight provisioning task. This runs before any branching, so it happens on every path.
3. :1077 find_managed_container_summary filters on A's id label and returns None, entering the "container gone, pending record present" branch.
4. :1082 container_name_for_sandbox(&record.sandbox) resolves to B's container name.
5. :1084 remove_container(force: true) force-removes B's running container.
6. :1092 cleanup_sandbox_token_file(&record.sandbox) deletes B's token file.
7. :1093 returns Ok(true), so the gateway reports A as deleted and broadcasts a Deleted event for A.

No error is surfaced anywhere. Two other call sites share the same lookup: stop_sandbox_inner:1135 (aborts and cleans up the wrong sandbox on stop) and pending_snapshot:1282, which backs GetSandbox and can return another sandbox's snapshot.

reserve_pending_sandbox:1250 applies the same id == || name == test, so two same-named sandboxes cannot be pending simultaneously. That is not required here: only B is pending, and A finished provisioning long before.

Container naming already handles this correctly — container_name_for_sandbox:3638 builds openshell-{workspace}--{name}-{id} specifically so names cannot collide. The pending lookup never received the same treatment.

Docker-driver only. The Podman driver has no equivalent pending map or matcher.

Impact / Why This Matters

Deleting or stopping a sandbox in one workspace silently destroys an unrelated, actively provisioning sandbox in another workspace: its provisioning task is aborted, its container is force-removed, and its gateway JWT is deleted. The owning tenant sees a sandbox vanish with no error and no log tying it to the other workspace's request. The delete that caused it reports success.

This is a cross-tenant blast radius on a shared gateway, and it requires no race — only two sandboxes with the same name in different workspaces, which the persistence layer explicitly permits.

The only workaround is enforcing globally unique sandbox names across all workspaces out-of-band. That defeats the purpose of workspace-scoped naming and cannot be enforced through any OpenShell-supplied mechanism, since the gateway itself generates names for unnamed sandboxes.

Acceptance Criteria

• pending_sandbox_matches identifies a record unambiguously: match on sandbox_id alone when it is non-empty, and fall back to name only when no id is supplied, scoped by workspace.
• Deleting a sandbox does not abort, remove the container of, or delete the token file of a same-named sandbox in another workspace.
• Stopping a sandbox (stop_sandbox_inner) has the same isolation.
• GetSandbox for a sandbox does not return a same-named pending sandbox from another workspace.
• Regression test covering a delete against a completed sandbox while a same-named sandbox in a different workspace is pending.

Reproduction Steps

1. Run a gateway with the Docker compute driver and two workspaces, alpha and beta.
2. Create sandbox demo in workspace alpha. Wait for provisioning to complete, so the driver clears its pending record.
3. Remove that container out-of-band: docker rm -f openshell-alpha--demo-<sbx-A-id>.
4. Create sandbox demo in workspace beta. While it is still provisioning, proceed immediately to the next step.
5. Delete sandbox demo in workspace alpha.
6. Observe that the workspace beta sandbox is gone: its provisioning task was aborted, its container was force-removed, and its token file under $XDG_STATE_HOME/openshell/docker-sandbox-tokens/<namespace>/<sbx-B-id>/sandbox.jwt was deleted. The delete of the alpha sandbox reported success.

Environment

• OpenShell: main at 118b250
• OS: any
• Runtime, deployment, or integration: Docker compute driver, single gateway serving more than one workspace. Not version-specific; pending_sandbox_matches has had this shape since the map was introduced.

[letv1nnn]

📋 triage-agent

Triage Assessment

Classification: validated-bug

Summary

Confirmed. Every load-bearing claim in the report holds against main at
118b250f: the matcher text and line numbers, the call ordering in
delete_sandbox_inner, the fallback branch operating on the popped record
rather than the requested id/name, the shared pending map, the gateway
always sending both id and name, and per-workspace name uniqueness.
Confidence: high — verified by reading the code and by executing a temporary
test that reproduced the cross-workspace pop directly (reverted afterward;
no working-tree changes).

Investigation

Matcher and blast radius. pending_sandbox_matches
(crates/openshell-driver-docker/src/lib.rs:2165) is verbatim as quoted and
never consults DriverSandbox.workspace, which does exist
(proto/compute_driver.proto:185). The pending map is a single
Arc<Mutex<HashMap>> per driver instance (lib.rs:569), and
sandbox_namespace is one flat gateway-config string (lib.rs:126, default
"default"), so all workspaces share it. Docker's ensure_workspace /
delete_workspace are no-ops (lib.rs:2105). Name uniqueness is
workspace-scoped as cited (persistence/tests.rs:684); ids are globally
unique (persistence/tests.rs:728).

Reproduction. A temporary test using test_driver_with_config (no Docker
daemon required) reserved sbx-B/demo/beta, then called
remove_pending_sandbox("sbx-A", "demo"). It returned B's record:
record.sandbox.id == "sbx-B", record.sandbox.workspace == "beta", and
container_name_for_sandbox on it yields openshell-beta--demo-sbx-b.
This is the regression test the acceptance criteria ask for, and it needs no
Docker mock. (container_name_for_sandbox:3638 also lowercases via
sanitize_docker_name; the format in the report is otherwise correct.)

Three corrections that widen the reported scope:

1. The damage is not gated on out-of-band container removal. Steps 1–2 —
   popping B's record and task.abort() — run unconditionally at
   lib.rs:1070-1075, before the container lookup. An ordinary delete of A
   aborts B's in-flight provisioning and drops B's pending record, so no
   failure event ever reaches the gateway and B is left half-provisioned with
   the gateway still believing it is starting. The out-of-band precondition
   gates only the container force-remove escalation in steps 4–6.

2. Stop is more destructive than delete, and the report understates it.
   stop_sandbox_inner:1135-1141 pops B, aborts B's task, deletes B's token
   file, and then calls publish_deleted(record.sandbox.id) — B's id. The
   gateway consumes that as apply_deleted("sbx-B")
   (openshell-server/src/compute/mod.rs:2866, :3288), which deletes B's
   row from the store and spawns a driver delete for B. Stopping A can
   destroy B end-to-end.

3. The chain is self-triggering. When A's container disappears, the
   driver's 2-second watch poll (lib.rs:75, :1466) emits Deleted(sbx-A),
   and the gateway routes that through apply_deleted →
   spawn_driver_sandbox_cleanup → call_driver_delete_sandbox
   (compute/mod.rs:3301, :3372, :3399) straight back into
   delete_sandbox_inner("sbx-A", "demo"). No operator action required.

Also note fail_pending_sandbox:1311 retains the record indefinitely for
failed sandboxes, so the exposure window is not bounded by provisioning
duration.

One acceptance criterion is not implementable as written.
GetSandboxRequest, StopSandboxRequest, StartSandboxRequest, and
DeleteSandboxRequest carry only sandbox_id and sandbox_name
(proto/compute_driver.proto:342-393). workspace is not available at any of
these call sites, so "scoped by workspace" would require a
compute_driver.proto change. The other half of the criterion — match on
sandbox_id alone when non-empty, fall back to name only when no id is
supplied — is implementable today, is what the VM driver already does
(openshell-driver-vm/src/driver.rs:1387), and closes every described
scenario, since ids are globally unique. Workspace scoping is redundant once
id takes precedence.

reserve_pending_sandbox needs a separate edit, and hides a second
defect. It does not call the helper; it inlines an equivalent predicate at
lib.rs:1252-1255. Fixing only pending_sandbox_matches leaves it in place.
The temporary test also confirmed that reserving alpha/demo then beta/demo
returns AlreadyExists — workspace beta cannot create a sandbox named
demo while alpha's demo is provisioning or has failed. That is a
distinct user-visible bug the issue does not claim, and the natural fix
touches the same two predicates.

GetSandbox impact is real but lower than implied. pending_snapshot:1282
can return the wrong record, but the two direct gateway consumers guard with
snapshot.id == sandbox_id (compute/mod.rs:1381, :2926), and the sweep
paths CAS on incoming.id with A's resource_version (:2980, :2996), so
the mismatch is rejected. Net effect is stale liveness for A, not corruption
of B.

Other drivers. Podman confirmed clean — no equivalent pending map.
Kubernetes: none. But VM (driver.rs:1387, :1461, :1525, :1609) and MXC
(driver.rs:349, :446) use unscoped name-fallback matching of the same
class; MXC's stop_sandbox matches by name alone. Per AGENTS.md scoping
rules those likely belong in separate issues rather than this branch.

Duplicates. None. #3041 touches the same function but is the disjoint
"container gone, no pending record" branch; the two fixes should be
coordinated but are not the same defect.

Age. pending_sandbox_matches was introduced unchanged in #1567
(ee637e1a, 2026-05-27) and ships in every release from v0.0.100 through the
current v0.0.116. Not a regression, and not version-specific as the reporter
states.

Existing coverage. Two positive asserts only, inside
pending_sandbox_snapshot_uses_docker_namespace_and_starting_condition
(crates/openshell-driver-docker/src/tests.rs:2880). No negative case, no
cross-workspace case, no coverage of remove_pending_sandbox or
reserve_pending_sandbox.

Impact Signals

• Affected users/scope: Docker compute driver only, on a gateway serving
  more than one workspace with a name collision across them. Severity depends
  entirely on whether that is a supported posture — see the disclosure note
  below. Within a single workspace the same code path is harmless, because
  names are unique there.
• Regression: No. Present since feat(docker): add provisioning progress events #1567 (2026-05-27), in all releases
  v0.0.100–v0.0.116.
• Workaround: As the reporter states, only out-of-band globally unique
  naming, which OpenShell cannot enforce — the gateway generates names for
  unnamed sandboxes. Confirmed unavailable.
• Evidence quality: High. Every claim traced to code; cross-workspace pop
  reproduced by execution.

Note for Maintainers: Disclosure Posture

The Docker driver is registered with_local_singleplayer
(openshell-gateway/src/lib.rs:160) and the docs position it for local
single-player gateways (docs/reference/gateway-config.mdx:214). Multi-workspace
Docker is architecturally reachable — workspaces are an authz boundary
independent of driver, and singleplayer mtls_auth defaulting is skipped when
OIDC is configured (openshell-server/src/cli.rs:841) — but whether it is a
supported posture is a maintainer call, and severity swings on the answer:
self-inflicted same-operator damage versus cross-tenant destruction. If
maintainers judge multi-tenant Docker supported, this is a tenant-isolation
weakness and handling should move to the private channel in
SECURITY.md rather than this public issue. I have
not applied topic:security; that classification is tied to the posture
decision.

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.

Two scoping questions worth settling at the same time: whether the fix should
also cover the spurious cross-workspace AlreadyExists on create, and whether
the analogous VM and MXC matching gets its own issue.