The e2e suite can delete a developer's real devpod workspaces

[blooop]

Question

Running the e2e suite on a host deletes that host's real devpod workspaces. Make
it impossible.

Graduated from the conflict-scoping ticket,
which found this while enumerating collisions. Three facts compose into a footgun:

• dl --purge deletes every workspace devpod list returns
  (devlaunch/dl.py:335-339) — it has no notion of "only mine".
• An e2e test exercises exactly that, for real, at
  test/e2e/test_full_workflow.py:266.
• devpod list reads ~/.devpod, not anything under XDG_*. So the scratch
  XDG_CACHE_HOME/XDG_CONFIG_HOME dance that CLAUDE.md prescribes does not
  protect you here. devlaunch never sets DEVPOD_HOME (grep -rn DEVPOD_HOME .
  is empty).

So pytest -m e2e run on a developer's machine — by habit, by a misconfigured
editor, by an agent that did not read the marker config — destroys their whole
workspace list. The addopts = "-m 'not e2e'" default in pyproject.toml:126 is
the only thing standing between a developer and that, and a default is not a
safeguard.

The same ticket found a second, milder instance: the suite's workspace ids are
hardcoded constants — e2e-test-{create,lifecycle,git,purge} at
test/e2e/test_full_workflow.py:52,86,136,235 — and teardown devpod delete --forces them, so two concurrent e2e runs delete each other's workspaces.

This is a wayfinder:build ticket: go through /tdd.

Test-first, and note the shape of the red test. The failing test cannot be
"run --purge and see what dies" — the red state of that test is the damage.
Write it at a seam instead: the thing under test is that the suite refuses to
touch state it did not create. Candidate seams, pick and justify one — a fixture
that refuses to run destructive e2e unless pointed at a scoped DEVPOD_HOME; a
guard asserting devpod list is empty or contains only this run's ids before any
--force delete; per-run unique ids so the constants stop being shared at all.

Prefer the smallest thing that makes the bad outcome unrepresentable rather than
merely unlikely (principles 2 and 3) — a guard that can be forgotten at the next
new test is weaker than a scoping that applies to the whole suite at once.

Scope note. Whether dl --purge itself should learn a narrower blast radius
in production is a separate question and is not this ticket — this ticket makes
the test suite safe to run. If the work suggests the production behaviour is
also wrong, say so on the ticket and let the map graduate it.

Relation to the daemon. Inside a dind devcontainer each run gets its own
~/.devpod and its own daemon, so the nested daemon fixes this incidentally.
That is not a reason to skip it: the suite must be safe when someone runs it
outside a container, which is precisely the case nobody is protected from today.

[blooop]

breadcrumb: seam chosen — process-environment scoping in the root conftest, not a per-test fixture and not a pre-delete guard. pytest_configure points DEVPOD_HOME (and DEVPOD_SSH_CONFIG) at a fresh per-run temp dir before collection, so every subprocess the suite spawns — including the devpod list inside dl --purge — inherits a namespace containing only what this run created. Chosen over per-run unique ids and a before-delete assertion because it is scoping rather than guarding: there is nothing a new test can forget to request, and it subsumes the per-run-id fix (a fresh namespace makes the hardcoded e2e-test-* constants private to the run) rather than adding a second overlapping concept.

Verified on metal (read-only), three facts this rests on: (1) DEVPOD_HOME=<scratch> devpod list --output json returns [] on a host with three real workspaces — the scoping is real. (2) A fresh DEVPOD_HOME has no providers, so the fixture must seed devpod provider add docker --use or e2e devpod up breaks; that seeding is itself scoped and left the real ~/.devpod/contexts/default/providers untouched. (3) devpod up writes its Host <id>.devpod block to the real ~/.ssh/config regardless of DEVPOD_HOME — but --ssh-config has an env twin, DEVPOD_SSH_CONFIG. That answers the map’\s open question in #93 ("does devpod write ssh config relative to $HOME or DEVPOD_HOME?"): neither — it is ~/.ssh/config unless DEVPOD_SSH_CONFIG says otherwise, and the same seam covers it with one more variable.

[blooop]

breadcrumb: red proved, then green. The e2e-level test — a real devpod list spawned the way the suite spawns everything, asserted disjoint from the ids read straight off ~/.devpod on disk — failed with exactly the three workspaces this host actually owns, then passed once the scoping went in. Three unit-level tests pin the mechanism on the default suite (not under -m e2e), so deleting the scoping breaks an ordinary pixi run test rather than waiting for the run that would do the damage. One thing metal forced that reading would not have: a fresh DEVPOD_HOME has no providers, so devpod up in it fails until docker is installed there — that seeding lives in an autouse session fixture in the e2e directory, which no new e2e test can forget and no unit run pays for.

[blooop]

breadcrumb: PR #106 opened — one slice: the suite gets a devpod namespace of its own, scoped in pytest_configure before collection. No devlaunch/ source file touched. Full default suite 811 passed, lint 10.00/10. The destructive path was verified end to end rather than argued: dl --purge -y was run for real against a synthetic scoped namespace holding one workspace, deleted exactly that one, and all three of this host's real workspaces survived.

Scope-note callout, for the map to graduate. Working this ticket did confirm the production behaviour is also wrong, and I left it alone as instructed. dl --purge deletes every workspace devpod list returns, with no notion of "only mine" — measured here, unscoped it would have deleted pythontemplate, a workspace devlaunch did not create and knows nothing about. The interesting part is that the ownership predicate already exists and is unused: every dl-created workspace id is derived from (owner, repo, ref) via WorkspaceId, and devlaunch tracks its own workspaces in metadata.json, so "mine" is answerable without a new concept. The candidate question is whether --purge should intersect the devpod list result with what devlaunch believes it created, and what it should then do about workspaces it finds but does not recognise — report them, or offer a separate opt-in flag.

[blooop]

breadcrumb: gate closed — CI green on #106 across py310-py313, prek and codecov. Destroyed nothing: this host's three real devpod workspaces (devlaunch-main-zovomobo, devlaunch-t1-vebilote, pythontemplate) and all six ~/.ssh/config DevPod blocks are exactly as they were before the ticket started, including across a real dl --purge -y run. Handing to review.

[blooop]

breadcrumb: build stage complete → in review. Gate checked from GitHub state: PR #106, head 7f90ada, 3 workflow runs present for that SHA (verified non-absent, not merely non-failing) and all checks green — py310–py313, prek, codecov patch+project, GitGuardian. Routing to /review in fresh context; the reviewer has not seen the code written.

[blooop]

breadcrumb: review posted on #106 — changes requested (posted as a comment; GitHub refuses --request-changes on a self-authored PR). The spec is met: DEVPOD_HOME/DEVPOD_SSH_CONFIG confirmed real on devpod v0.26.1, and every devpod spawn in the tree inherits rather than replaces the environment — run_devpod's one env= caller builds from os.environ, so the seam holds. One blocking test-integrity defect: test_each_run_gets_a_devpod_home_of_its_own stays green with scope_devpod_to_this_run() commented out — it asserts tempfile.mkdtemp's contract, not this PR's, so the claim that it catches a fixed-path regression is false. Three should-fixes: the new e2e autouse fixture runs devpod provider add docker --use unguarded (its safety rests on the very scoping it should assert), it swallows the failure, and DEVPOD_SSH_CONFIG is registered only on devpod up — devpod ssh/delete still read the real ~/.ssh/config, so the map answer needs that qualifier.

[blooop]

breadcrumb: review gate → needs attention. Blocking finding: test/unit/test_devpod_scoping.py:47-57 stays green when scope_devpod_to_this_run() is commented out — it asserts mkdtemp's own contract, not this PR's code, so the PR's claim that it catches the fixed-path regression is false as written. Three should-fix findings besides. Routing to one fresh retry subagent; a second failure parks this ticket.

[blooop]

breadcrumb: review findings addressed on #106 (f8c551a, 615df48); CI green on all nine checks at head 615df48. Blocking finding fixed by making the test drive scope_devpod_to_this_run itself rather than mkdtemp — red proved by mutation on metal and restored: commenting out the call in pytest_configure reds the two env tests (assert None) and the new e2e provider guard; replacing the per-run mkdtemp with a fixed path reds test_each_run_gets_a_devpod_home_of_its_own on assert first != second with both identical paths printed. The old version was green under both, so make_scoped_devpod_home lost its only caller and is inlined away. Should-fixes: the e2e provider fixture now asserts DEVPOD_HOME before its --use write and raises the install stderr instead of discarding it; the ssh-config test is renamed to test_devpod_up_is_... with the limit measured again here (devpod v0.26.1: --ssh-config on up only, ssh/delete/stop 0, while --devpod-home is persistent-root). Map qualifier, and it was observed live: because devpod delete does not take --ssh-config, a scoped run still prunes its own blocks from the real ~/.ssh/config — two such blocks vanished from this host during the session, for workspaces absent from ~/.devpod, while nothing in this repo writes ssh config. The developer's three workspaces (devlaunch-main-zovomobo, devlaunch-t1-vebilote, pythontemplate), their three ssh blocks, and the whole ~/.devpod tree (md5 over every file) are byte-identical start to end. Full e2e suite still not run — individual tests by node id only.

[blooop]

breadcrumb: retry addressed all five findings; CI green at head 615df48 with 3 workflow runs present. Blocking finding fixed by rewriting rather than deleting the test — it now drives scope_devpod_to_this_run() itself, and the fixed-path mutation makes it fail. Middle-man helper make_scoped_devpod_home deleted. Both mutation transcripts pasted on the PR. Routing to a focused verification pass.

[blooop]

breadcrumb: verification pass on #106 at 615df48 → approve. All five findings re-checked independently rather than read off the author's reply. The blocking one is fixed the harder way: the rewritten test_each_run_gets_a_devpod_home_of_its_own goes red under three separate mutations, not two — commenting out scope_devpod_to_this_run() reds the two env tests, the fixed-path mkdtemp reds the uniqueness test, and a third mutation added here (unique directory but a fixed DEVPOD_HOME written to the environment) reds it on the second assertion. That last one is the shape that would slip past a test asserting only on the return value, so both assertions are load-bearing. Order-independence checked too, since pytest-randomly is on and this is the file's only os.environ mutator: uniqueness-test-first passes, five random orders pass. The e2e guard was proven to fire before any write by importing the fixture with DEVPOD_HOME unset and subprocess.run sabotaged to raise if reached — it never was. DEVPOD_SSH_CONFIG's subcommand scope re-measured here on devpod v0.26.1 (up: 1, ssh/delete/stop: 0, --devpod-home on all four) and the qualifier is on the #93 map answer, which is what the review actually asked for. Nothing new introduced: 820 collect, 811 passed / 9 deselected, pylint 10.00/10. Destroyed nothing — ~/.ssh/config md5 6cf324ea… and the whole ~/.devpod tree md5 ff044f9b… byte-identical before and after, three real workspaces intact, no devpod delete issued and the full e2e suite not run. Two non-blocking residuals named on the PR: the test's tempfile.tempdir containment is coupled to mkdtemp() taking no dir=, and test/devpod_scoping.py now holds a generic top-level name on the suite's sys.path.

[blooop]

breadcrumb: stage → in review, approved. This is where an unattended lifecycle ends: PR #106 is green at 615df48 and approved by an independent verification pass, and merging is reserved for you. No steering line granted merge-when-green, so I am not merging it.

The verification was not a rubber stamp — it re-ran both of the author's mutations itself and added a third the author had not tried: a unique directory but a fixed DEVPOD_HOME written to the environment, which is the shape that slips past a test asserting only on the return value. The test caught it. It also chased the predecessor's failure class specifically — order dependence, since pytest-randomly is on by default and this is the file's only os.environ mutator — across five random orders. Clean.

Two non-blocking residuals recorded on the PR rather than fixed: monkeypatch.setattr(tempfile, "tempdir", …) contains the throwaway homes only because scope_devpod_to_this_run calls mkdtemp() with no dir= — add an explicit dir= later and the test still passes while leaking two real /tmp dirs per run; and test/devpod_scoping.py now occupies a generic top-level name on the suite's sys.path.

This ticket stays open until the PR merges, which is also what keeps #107 correctly blocked — it needs this harness to test the production --purge fix safely.