What actually conflicts between two concurrent devlaunch efforts on one host?

[blooop]

Question

What actually conflicts today when two devlaunch efforts run on one host, and
which of those conflicts does a nested Docker daemon fix?

The destination is "several branches developed and e2e-tested concurrently
without conflict", but the conflicts have never been enumerated, and the repo
already carries two isolation mechanisms that overlap:

• Per-branch workspaces. dl owner/repo@branch already gives each branch its
  own clone, workspace id and container. That is isolation the host already has.
• Scratch XDG dirs. CLAUDE.md documents
  XDG_CACHE_HOME=/tmp/dl-scratch/cache XDG_CONFIG_HOME=/tmp/dl-scratch/config dl-next ...
  and is explicit that this "isolates the bookkeeping, not the machine — dl
  drives devpod and docker on the host either way, so the workspaces a scratch
  run creates are real ones that devpod list shows".

So enumerate the real collision surface and attribute each item. Candidates to
confirm or dismiss from the source, not from memory: metadata.json and the bare
clone cache under XDG_CACHE_HOME; the shared devpod list namespace and
workspace-id derivation (devlaunch/workspace_id.py); container name and port
collisions on the host daemon; the bare-clone directory layout; the host's
~/.ssh config entries for *.devpod.

Then say, per item, which of the three mechanisms resolves it — per-branch
workspace, scratch XDG dirs, or nested daemon — and whether any of the three is
made redundant by another. Principle 2: if two mechanisms cover the same
collision, the map should end up recommending one.

This ticket is deliberately unblocked: it scopes what the prototypes downstream
are allowed to conclude, and it can be answered by reading the tree.

How the outcome gets tested. No code; the answer is a table on this ticket
that later tickets cite. Its claims about devlaunch's behaviour must each name
the file and line they come from.

[blooop]

breadcrumb: verified on metal — devpod does not name containers by workspace id (host shows sleepy_spence/zen_easley for the two live devlaunch workspaces; the workspace id appears in the image tag, devlaunch-main-zovomobo-8dd17:devpod-…). So "container name collision" is dismissed as a candidate. What is named by workspace id: the devpod workspace (--id, dl.py:944), the clone leaf dir (workspace_clone.py:83), the ~/.ssh/config Host <id>.devpod block, and the pixi volume ${localWorkspaceFolderBasename}-pixi (.devcontainer/devcontainer.json:47) — all per-branch unique, all derived from (owner,repo,ref) only (workspace_id.py:204), i.e. independent of XDG_CACHE_HOME.

[blooop]

breadcrumb: found the collision that actually blocks the destination, and it is not a daemon problem. dl --purge deletes every workspace devpod list returns (dl.py:335-339) — and an e2e test runs it (test/e2e/test_full_workflow.py:266). The suite sets XDG_CACHE_HOME on that call (:244), which does nothing, because devpod list reads ~/.devpod, not XDG. devlaunch never sets DEVPOD_HOME (grep across the repo is empty) even though devpod v0.26.1 exposes it (devpod --help: --devpod-home … DEVPOD_HOME, verified on the host). Same file also hardcodes workspace ids e2e-test-create/-lifecycle/-git/-purge (:52,:86,:136,:235), so two concurrent e2e runs fight over one devpod workspace and one ~/.ssh/config Host block.

[blooop]

breadcrumb: verdict forming, and it cuts against the map's framing. Every collision the enumeration turned up is fixed by one of three cheap things — per-branch ids (already shipped), DEVPOD_HOME scoping (exists, never used), per-run e2e ids — none of which is a daemon. The nested daemon is strictly stronger than scratch XDG dirs (a container has its own $HOME and its own XDG, so it subsumes them), so principle 2 forces a choice there and scratch XDG loses. But the daemon's justification is capability, not conflict: dl's only subprocess is devpod (dl.py:781), and devpod needs a daemon, so dl cannot run inside a container that has none. Writing that up.

[blooop]

agent-decided (simplicity):

The three "isolation mechanisms" are not three answers to one question. They
answer three disjoint questions, and only one of the three is about concurrency
at all. Enumerated below; every behavioural claim cites file:line, and the rows
marked (metal) were read off this host rather than off the source.

The collision table

Shared thing → does it actually collide between two concurrent efforts, and what
resolves it.

#	Shared resource	Collides?	Evidence	Resolved by
1	devpod workspace id / the devpod list namespace	No, for dl-created workspaces	id is (owner, repo, ref) hashed + slugged, workspace_id.py:204,219; handed to devpod as --id, dl.py:944	per-branch workspaces
2	clone directory leaf under XDG_CACHE_HOME/devlaunch/repos/<owner>/<repo>/	No	leaf is WorkspaceId.value, workspace_clone.py:81-83; repo root repo_manager.py:36-38	per-branch workspaces
3	~/.ssh/config — devpod's Host <id>.devpod blocks	No, for dl workspaces	(metal) host holds # DevPod Start devlaunch-main-zovomobo.devpod and …-t1-vebilote.devpod, one block per workspace id	per-branch workspaces
4	docker image tag	No	(metal) docker ps -a → image devlaunch-main-zovomobo-8dd17:devpod-d0921eb…; tag carries the workspace id	per-branch workspaces
5	docker container name	No — dismissed	(metal) docker ps -a names are docker-random (sleepy_spence, zen_easley). devpod does not name containers by workspace id	nothing needed
6	the ${localWorkspaceFolderBasename}-pixi volume	No via dl. YES via pixi run dev	.devcontainer/devcontainer.json:47. Via dl the basename is the workspace id (row 2) → unique. Via pixi run dev (devpod up ., pyproject.toml:74,76) it is the checkout directory name → (metal) the host carries main-pixi, t1-pixi, w1-pixi, w2-pixi, bugfix1-pixi beside devlaunch-main-zovomobo-pixi; any two repos with a worktree dir named main share one volume	per-branch workspaces, but only if the pixi run dev* tasks are retired in favour of dl
7	metadata.json	YES — lost update	loaded whole at construction (storage.py:69-74), rewritten whole on every mutation (storage.py:247-251), no lock anywhere (grep -rn 'flock|fcntl|filelock' devlaunch/ is empty). Two dl processes: A loads, B loads, A saves, B saves → A's entry gone	scratch XDG (storage.py:28-33) — or a lock, which is the real fix
8	the shared bare clone …/<owner>/<repo>/.bare	YES — git-level	every branch of one repo shares one bare repo (repo_manager.py:40-42); concurrent git fetch origin +refs/heads/*:refs/heads/* (repo_manager.py:117-121) and git branch into it (branch_manager.py:71-73 via workspace_clone.py:190-196) contend on git's own ref/packed-refs locks	scratch XDG (at the cost of a fresh full clone) — or git's own locking, which is already correct, merely noisy
9	completions.json / completions.bash	Benign	atomic-rename, last writer wins (dl.py:118-130,133-155); content is regenerated from devpod list + a cache-dir scan, so a lost write self-heals within COMPLETION_CACHE_TTL_SECONDS (dl.py:98)	nothing needed
10	the host network namespace	YES	.devcontainer/devcontainer.json:29-31 sets runArgs: ["--network=host"]. Two copies of this devcontainer are then in the host netns and cannot both bind any port	dropping --network=host — which #69 already does, though for the netns reason, not this one
11	e2e workspace ids	YES	hardcoded constants e2e-test-create, e2e-test-lifecycle, e2e-test-git, e2e-test-purge — test/e2e/test_full_workflow.py:52,86,136,235. Two concurrent runs fight over one devpod workspace and one ~/.ssh/config block, and each run's teardown devpod delete --forces the other's (test/fixtures/e2e_helpers.py:160-168)	per-run unique ids. Not per-branch workspaces — these never go through WorkspaceId, they call devpod up --id directly. Not scratch XDG — the suite already sets XDG_CACHE_HOME on those calls (:58,98,148,244) and still collides
12	~/.devpod — the whole workspace list	YES, and this is the worst one	dl --purge deletes every workspace devpod list returns (dl.py:335-339), and an e2e test runs it (test/e2e/test_full_workflow.py:266). devpod list reads ~/.devpod, not XDG, so the XDG_CACHE_HOME on that call (:244) buys nothing. devlaunch never sets DEVPOD_HOME — grep -rn DEVPOD_HOME . is empty — although devpod v0.26.1 exposes it (metal: devpod --help → --devpod-home string … You can also use DEVPOD_HOME)	DEVPOD_HOME scoping. A nested daemon also covers it, by giving the effort a different $HOME

Attribution, rolled up:

• per-branch workspaces → rows 1, 2, 3, 4, 6
• scratch XDG dirs → rows 7, 8 (and 9, vacuously)
• nested daemon → rows 10, 11, 12 — and 7, 8, as a side effect of the
  container having its own $HOME and its own XDG

The redundancy judgement

Scratch XDG dirs are redundant and should leave the map's mechanism list.
Everything they cover — rows 7 and 8 — a nested daemon covers too, strictly and
for free, because a container has its own $HOME and therefore its own
~/.cache/devlaunch. Two mechanisms, one collision set, so principle 2 picks
one, and it is not the weaker one. CLAUDE.md should keep the paragraph but stop
calling it isolation: it is a blast-radius guard for editing storage.py, and
its own text already says so ("isolates the bookkeeping, not the machine"). The
map should not count it as a third mechanism.

Per-branch workspaces stay, unconditionally. They are always on, cost
nothing, and are the only thing covering rows 1-4. No other mechanism competes
for that work. This also settles one of the map's open questions: one
devcontainer per branch, not one shared devcontainer opening many nested
workspaces — a shared container would reintroduce rows 1-4 inside itself, and
the derivation that prevents them is per-(owner, repo, ref)
(workspace_id.py:204), not per-host.

The nested daemon stays — but not for any reason in this table. This is the
uncomfortable part, and it scopes every downstream ticket. Rows 10, 11 and 12 are
the only collisions left, and each has a fix an order of magnitude smaller than a
nested daemon:

• row 10 → delete two lines of runArgs
• row 11 → make four test constants unique per run
• row 12 → set DEVPOD_HOME, a flag devpod already has and devlaunch has never used

Do those three and two efforts run concurrently on one host, on the host's own
Docker, without conflict. So the nested daemon is sufficient for concurrency
but is nowhere near minimal for it, and the map must stop selling it as the
concurrency fix. Its actual justification is capability, and the map's own
destination states it: dl must work inside that container. dl's only
subprocess is devpod (dl.py:781, the single spawn point, deliberately so per
its docstring at dl.py:776-779), and devpod's docker provider needs a daemon —
so dl in a container with no daemon cannot do anything at all. That is the
claim #69 never made and this map's second job is to prove.

What this scopes for downstream tickets

1. A prototype may conclude the nested daemon delivers dl-inside-the-container.
   It may not conclude the nested daemon fixes concurrency — rows 10/11/12
   are the whole of "concurrency", and each is separately and more cheaply
   fixable.
2. Rows 10, 11, 12 are three independent defects, each ticketable today, each
   testable without a daemon. Row 12 is the one that costs a colleague their
   workspace list, and it is one env var.
3. Row 7 (metadata.json lost update) is a real bug that neither remaining
   mechanism should be answering. It wants a lock in storage.py, not an env
   var and not a container.

What could not be settled from the source

• Whether dropping --network=host (row 10, and Give the devcontainer its own Docker daemon for e2e testing #69) breaks Claude Code's OAuth
  flow in this devcontainer. .devcontainer/claude-code/README.md:68-88 states
  host networking is "critical for OAuth authentication ... OAuth callbacks can't
  reach the container" without it; Give the devcontainer its own Docker daemon for e2e testing #69 removes it and says nothing about that.
  This is a genuine conflict between two documents in the tree and cannot be read
  out of either — it needs a container built and an auth attempted. Deserves its
  own ticket, and it blocks Give the devcontainer its own Docker daemon for e2e testing #69 independently of the dockerd-starts claim.
• Whether devpod writes its ~/.ssh/config blocks relative to $HOME or to
  DEVPOD_HOME. If the former, DEVPOD_HOME scoping alone still leaves row 11's
  ~/.ssh/config contention, and row 11 must be fixed at the id, not at the
  namespace. Settled by one DEVPOD_HOME=… devpod up and a diff of
  ~/.ssh/config — a metal question, not a source one.