The trip floor, not the trip count: how dl reaches into a running container

[blooop]

Question

How does dl reach into a running container, given that the trip itself — not the
number of trips — is now the dominant cost?

A cold launch makes three devpod ssh trips (probe, transfer, attach) and a warm
launch makes one. Each carries a 2.07-2.33s floor with an empty payload, so
the floor alone is ~7s of a 13-15s cold launch and ~75% of a 2.7-3.5s warm one.
Trip-removal has run out: #157
took the cold path 4->3 and refused the probe->transfer merge, because merging
either always streams the payload on the very path the three-state probe exists to
keep free, or hands the container back its own copy of the official-layout
relation — the two-predicate drift #151
spent three review rounds removing. That refusal stands and this ticket does not
reopen it. It attacks the other factor.

Two candidate answers, and they are alternatives to one question rather than two
tickets, which is why they are decided together:

(a) Multiplex the ssh connections. ControlMaster=auto +
ControlPersist over devpod's own generated ssh config takes a second trip from
1.85s to 0.010s, measured. A pty-requesting trip with SendEnv reuses the
master too (1.92s -> 0.015s, env still arriving), so the attach shape is not
excluded. Because ControlPersist outlives the process, a master opened by one
dl is reusable by the next dl — which is the only thing that would help the
warm path, where there is a single trip and nothing to amortise within one run.

(b) docker exec for the non-interactive trips. 0.07s against 2.3s on the
same container, and the transfer measures 0.43s against 1.76s (below). But this
cuts against a documented architectural commitment: dl's only subprocess is
devpod (CLAUDE.md, and the reason the devcontainer insists on the project env's
devpod rather than whatever is on PATH). A docker path is provider-specific —
it is simply absent for any non-docker provider — so it can only ever be a fast
path with the ssh path underneath it, which is a second way of doing one thing
and owes principle 2 an argument.

What the answer has to settle:

• Which of (a), (b), both-with-(b)-as-a-fast-path, or neither. Consistency with
  the route already walked matters here: this map has repeatedly preferred one
  mechanism over a fast path plus a fallback.
• Where the control path lives and who cleans it up. A socket per workspace under
  XDG_RUNTIME_DIR or the cache dir; what ControlPersist value; what happens
  to a master whose container was recreated under it (a devpod up --recreate
  between two launches is the case), and whether that fails closed.
• Whether dl invoking ssh directly is acceptable at all, since it means dl
  grows a second subprocess dependency and has to know devpod's ssh-config path
  and host-alias shape (<id>.devpod) — both of which are devpod's private
  arrangements today.
• What it does to interpret() / StderrFilter, which read devpod's stderr to
  recover the remote exit status. Bypassing devpod means recovering that
  status a different way, and getting it wrong silently converts a remote
  failure into a success.
• How it is tested. The spawn-count suite is this map's existing structural pin
  (test_devpod_spawn_counts-style, plus the cold pins One cold-path setup pass: fold the hostname into the probe's round trip, with per-stage outcomes #168 added); a trip that
  becomes cheap must not become invisible to that pin, and "connection
  reused" wants a pin of its own.

Blocked on the research ticket for the devpod-side facts.

Where these numbers come from

All figures below were measured on 2026-08-24 against the Rust build
(rust/target/release/dl, dl 0.13.0), driven from inside this repo's own
devcontainer (nested docker-in-docker, devpod 0.26.1, docker 29.7.2, 8 CPUs).
DEVPOD_HOME, DEVPOD_SSH_CONFIG and XDG_CACHE_HOME were scoped to a scratch
directory; the target was blooop/dotfiles with a warm image and a warm bare
clone cache.

Caveat, and it is not small: nested DinD is not the host. Absolute seconds
here run higher than a host launch, and this is not the CI trend point
#292 is about. What transfers
is the ratios and the floors — the pieces are A/B'd against each other in one
environment. The host cross-check is that README's own host medians (warm
2.176s, cold-recreate 15.899s) sit close to what was measured here (warm
2.7-3.5s, cold 13.1-15.5s).

[blooop]

breadcrumb: two things inherited from #393, which settled the devpod status half and deferred the provider-specific half here.

A new fact about where the time goes. The 0.55s of devpod status is devpod re-invoking its own binary as the docker provider's status command, not CLI startup — devpod --help is 0.048s. So "devpod is slow to start" is the wrong model for this map; the cost is devpod's provider indirection, and that is what a fast path would be skipping.

A type constraint this ticket must honour if it admits any provider fast path. It has to be an implementation of devpod::status behind the same signature — Result<ContainerState, StatusUnreadable>, all five ContainerState arms live — with no consumer able to learn which answered. A fast path that narrows the answer type, or that callers can distinguish, is refused: that is how a two-mechanism seam becomes two predicates that drift, which is the failure #151 spent three review rounds removing.

And a hazard for anything here that considers "just try it and fall back": devpod ssh <ws> --command against a Stopped workspace does not fail. It starts the container and exits 0 (4.04s vs 2.0s running; no flag on 0.26.1 refuses). Measured in #393. Any cheap-trip design has to assume a trip can silently perform an up.

[blooop]

breadcrumb: unblocked — #389 is closed with its findings on branch research/devpod-ssh-trip. Read that resolution before this ticket's own body: two of the premises written into this ticket did not survive it. The framing that a trip is "~99% connection setup" is wrong (the 1.8s is the in-container agent binary printing its own version twice, ~0.78s of it telemetry; KEX+auth+exec is 11ms and the real floor is ~75-150ms), and SendEnv does not survive a reused master unless the master itself declared the variable, silently and at exit 0 — which for dl means an empty GH_TOKEN and an unauthenticated gh with no error. Decide against what #389 measured, not against what this body assumed.

[blooop]

breadcrumb: this ticket's third bullet — "whether dl invoking ssh directly is acceptable at all, since it means dl grows a second subprocess dependency and has to know devpod's ssh-config path and host-alias shape" — is already answered by shipped code, in the affirmative.

rust/devlaunch-core/src/clients/ssh.rs is an OpenSSH transport. It builds ssh -t [-o SendEnv=GH_TOKEN] <id>.devpod <payload> (command_args), reads devpod's config to see whether the alias exists (devpod_host_configured, host_published, matching # DevPod Start as a whole line), and flows/launch.rs::route sends a command down it whenever there is a usable terminal. So dl <spec> -- <cmd> typed at a terminal — this map's destination sentence — runs over OpenSSH today, not over devpod ssh. devpod ssh --command carries only the trips with no terminal to hand over: the probe, the transfer, and a redirected command. docker is also already a subprocess (clients/docker.rs, volume removal), so CLAUDE.md's "dl's only subprocess is devpod" describes an intention, not the tree.

Reproduced on a scratch rig (devpod 0.26.1, docker 29.7.2, scratch DEVPOD_HOME/DEVPOD_SSH_CONFIG/XDG_CACHE_HOME, one-line devcontainers/base:ubuntu workspace, deleted afterwards; load average 21 — every absolute number here runs 2-3x above #389's rig, so only ratios travel):

	ms
ssh -t fresh, ControlMaster=no	2590, 2893, 3140
ssh -t reused over a master	16, 22, 23, 25, 28
devpod ssh --command true	6193, 6848, 7214, 7357
devpod status --output json	1394, 1677, 2010

~100x, on the transport dl already runs, from -o flags on an argv dl already builds. #389's silent-GH_TOKEN hazard reproduced exactly: a master opened without SendEnv=GH_TOKEN, reused by a client passing it, returned GOT=[] at rc=0. A master opened with it returned the client's value. Remote status 7 came back as 7 through the master. An idle master reused fine at 40s (22ms) and at 70s — past a ControlPersist=60 window — OpenSSH had already unlinked the socket and the next trip was an ordinary 1972ms. Self-cleaning, and no keepalive interaction.

And a prerequisite this map did not know it had. config_path() hardcodes ~/.ssh/config. On this rig ~/.ssh/config does not exist — devpod wrote its block only to $DEVPOD_SSH_CONFIG, as #389 noticed in passing. So on any host that sets DEVPOD_SSH_CONFIG (which is what this repo's own scratch convention and test/conftest.py do), devpod_host_configured answers false, route returns DevpodCommand, and dl silently loses the pty transport it has — before any question of making it faster.

[blooop]

breadcrumb: two measurements that close two of this ticket's four options, on the same scratch rig.

1. dl cannot name the container, so no docker path starts. devpod 0.26.1's docker driver puts no devpod.* workspace label on the container it creates. The labels are the base image's own plus dev.containers.id=default-g3-ddb2a, dev.containers.* and devpod.user=root; docker ps --filter label=devpod.workspace=g390a returns nothing. The only handle is dev.containers.id, whose value is devpod's workspace UID (default-g3-ddb2a), a composed string that appears on disk only inside devpod's own contexts/<ctx>/workspaces/<id>/workspace.json and workspace_result.json. So any docker exec or docker inspect fast path begins by either re-deriving devpod's UID scheme or parsing devpod's private state files — dl holding its own copy of "which container is this workspace", which is the #151 two-predicate shape before a single command has run. (The container's Config.Env does carry DEVPOD_WORKSPACE_ID=g390a and DEVPOD_WORKSPACE_UID=default-g3-ddb2a, but docker has no env filter, so reading it means inspecting every container on the host.)

2. The telemetry cost is not reachable from dl. #389 left this as "the single most valuable open thread — a ~40% cut to the trip that asks nothing of dl's architecture", and asked whether dl, which controls the environment it hands devpod, can get at it. Answer: no. The lever is real and reproduced — in-container agent devpod version 843/789/922 ms, and 528/662/429 ms under docker exec -e DEVPOD_DISABLE_TELEMETRY=true, two of those per trip — but every switch that would set it is out of dl's hands:

• devpod up --workspace-env DEVPOD_DISABLE_TELEMETRY=true does not reach the container's Config.Env. Measured on a workspace created with exactly that flag: Config.Env is DEVPOD=true, REMOTE_CONTAINERS=true, DEVPOD_WORKSPACE_ID, DEVPOD_WORKSPACE_UID, PATH, LANG and nothing else. --workspace-env is applied to the session devpod's ssh server hands out, not to the container, so no docker exec devpod makes can inherit it — and the agent injection and the two version execs are docker execs.
• No provider or context option adds container env. devpod provider options docker is four options (DOCKER_BUILDER, DOCKER_HOST, DOCKER_PATH, INACTIVITY_TIMEOUT); devpod context options has TELEMETRY, which What a devpod ssh trip costs per connection, and whether it can be reused #389 already measured as reaching only the host process (~350 ms of host-side flush).
• The only remaining lever is the container's own Config.Env, which comes from the image and from containerEnv in the user's devcontainer.json. dl does not own that file and is not going to start writing it.

So this is an upstream fix (drop detectRemoteAgentVersion's redundant second version exec, or forward the telemetry switch into buildExistsCheck's guard), against github.com/skevetter/devpod — not a dl change and not a slice this repo can merge. Recorded as such below.

[blooop]

breadcrumb: the parity fact, measured because it decides whether the other trips could ever join this transport — and it is better than expected. An OpenSSH session through devpod's own alias is environment-equivalent to devpod ssh --command, including the workspace env dl sets on up:

devpod ssh --command   -> VIA_DEVPOD=[true] user=vscode pwd=/workspaces/g390a
ssh over a reused master -> VIA_SSH=[true]    user=vscode pwd=/workspaces/g390a
ssh, bash -lc            -> LOGIN=[true]

([true] is the value of a variable set only by devpod up --workspace-env, which is how dl delivers PIXI_CACHE_DIR.) Same user, same working directory, same variable — because the ProxyCommand starts the same devpod helper ssh-server. And a payload streams over it: 100 MB into cat > file took 4609 ms over a reused master against 7440 ms over devpod ssh --command, both arriving at 104857600 bytes.

So "move the probe and the transfer onto the same transport" is not blocked by an environment difference, which is what I expected to find blocking it. It is blocked by something else, and that is why it is graduated as a grilling rather than decided here: it would make the alias-not-published fallback correctness-critical rather than cosmetic, since the two paths recover a remote exit status by different mechanisms (ssh's own status against devpod's stderr sentence, which interpret/StderrFilter parse). Two command-trip mechanisms whose failure vocabularies differ is the shape this map has refused three times.

[blooop]

agent-decided (1):

The answer

dl reaches into a running container the way it already does — OpenSSH, over the alias devpod up publishes — and that connection is reused. No docker path, no second transport, no provider gate. The change is ControlMaster/ControlPath/ControlPersist as -o flags on an argv clients/ssh.rs already builds, plus the fix that makes that argv reachable in the first place.

Both of this ticket's candidates were framed as new machinery. One of them was not new: dl has run OpenSSH into containers since M3. clients/ssh.rs builds ssh -t [-o SendEnv=GH_TOKEN] <id>.devpod <payload>, devpod_host_configured reads devpod's config for the alias, and launch.rs::route sends a command down it whenever there is a usable terminal — so dl <spec> -- <cmd> typed at a terminal, this map's destination sentence, is an OpenSSH trip today. devpod ssh --command carries the trips with no terminal to hand over: the probe, the transfer, a redirected command, and a bare attach. And docker is already a subprocess too (clients/docker.rs), so CLAUDE.md's "dl's only subprocess is devpod" is an intention rather than a description, and the ticket's worry about "a second subprocess dependency" is a bill already paid.

That reframes the whole question. Option (a) is not "add multiplexing to dl", it is "stop opening a new connection for a transport dl already has". Nothing is added.

What the options were, and what happened to each

(a) Multiplex the OpenSSH transport — taken

Measured on a scratch rig (devpod 0.26.1, docker 29.7.2, scratch DEVPOD_HOME/DEVPOD_SSH_CONFIG/XDG_CACHE_HOME, one-line devcontainers/base:ubuntu workspace, deleted afterwards). Load average 21 for the whole run, so absolute seconds sit 2-3x above #389's rig and only ratios travel: ssh -t fresh 2590/2893/3140 ms against reused 16/22/23/25/28 ms. About 100x, reproducing #389's 150-200x under load. First breadcrumb has the table, the fail-closed re-checks and the idle-window behaviour.

It costs nothing to build and it buys nothing on a single cold launch. Both halves of that need saying plainly:

• There is exactly one OpenSSH trip per dl run, so there is nothing to amortise within a run. ControlPersist outliving the process is the entire mechanism: the win is on the 2nd..Nth launch into a live workspace, and on concurrency — What a devpod ssh trip costs per connection, and whether it can be reused #389's per-workspace lock turns N non-multiplexed trips to one workspace into a 2s staircase (9.9s..23.9s for eight), where the same eight over one master all finished at 8.02s. A fleet of agents attaching to one workspace is this repo's own lived case, and that is a correctness-adjacent win (a launch that waits 20s because seven siblings are launching) rather than a cosmetic one.
• The headline warm number moves by nothing on a first launch and by ~1.9s on a repeat, and the cold number does not move at all. Said flatly because this map states its destination in measurements.

(b) docker exec for the non-interactive trips — refused

Refused on principle (1), and the finding that decides it is new: devpod's docker driver puts no devpod.* workspace label on the container. Measured labels are the base image's own plus dev.containers.id=default-g3-ddb2a and devpod.user=root; docker ps --filter label=devpod.workspace=<id> returns nothing. The only handle is devpod's workspace UID, which lives on disk only inside devpod's private workspace.json / workspace_result.json. So a docker path begins by having dl re-derive or parse devpod's own "which container is this workspace" relation — a second copy of somebody else's predicate, before a single command has run. That is #151's two-predicate drift and #157's refusal in a new place, and #151's own review lesson names the failure mode: a guard that reads someone else's artifact is only correct until they change it.

Three more, each independently sufficient:

• It cannot honour The pre-up devpod status call costs 0.43-0.74s on every launch #393's constraint at this seam. For status the constraint is satisfiable — one signature, one answer type. A command trip's answer type is not shared: devpod::session returns SshOutcome and needs interpret/StderrFilter to recover a remote status devpod loses; ssh::run returns the status directly; docker exec puts its own failures (125/126/127) in the same integer space as the remote program's and has no -t equivalent for the pty path. Three vocabularies, and a consumer can tell them apart.
• It bypasses what makes the container a workspace. The 1.8s a docker exec skips is devpod's agent injection and version check — the thing that establishes the container is provisioned this generation. Skipping it is not a faster way to ask the same question.
• It is slower than the mechanism it would sit beside. docker exec is 13-27x; a reused master is 100-200x. A fast path that is 4-8x slower than the one-mechanism answer, on the path that answer already covers, has no case at all.

docker inspect as a status fast path — refused, and this closes #393's deferral

#393 deferred this here with a type constraint attached. I honour the constraint, and the constraint is what refuses it. The same container-naming problem applies. On top of it: docker inspect yields docker's words (running, exited, created, paused, restarting, removing, dead) and ContainerState holds devpod's (Running, Busy, Stopped, NotFound, Unknown(String)). A fast path behind that signature has to carry dl's own copy of devpod's docker-state-to-devpod-word mapping, and all five arms live means dl must also decide when docker's answer is Busy — a state that is about devpod's activity, not the container's. Then #393's second clause — no consumer may learn which answered — makes the drift silent: two mappings, one signature, and nobody downstream able to tell which spoke. Honoured faithfully, the constraint converts a latency win into an undetectable disagreement. devpod status stays the only implementation, exactly as #393 left it.

Attack the agent-version / telemetry cost directly — refused as unreachable from dl

#389 called this the most valuable open thread: ~0.78s of every trip, ~40%, asking nothing of dl's architecture. The lever reproduces (in-container agent devpod version 843/789/922 ms; 528/662/429 ms under docker exec -e DEVPOD_DISABLE_TELEMETRY=true, two per trip). dl has no hand on it, and the second breadcrumb has the measurements: devpod up --workspace-env DEVPOD_DISABLE_TELEMETRY=true does not reach the container's Config.Env (verified on a workspace created with that exact flag — Config.Env is six entries and that is not one of them), because --workspace-env decorates the session devpod's ssh server hands out, while the injection and both version calls are docker execs into the container. No provider or context option adds container env. The only remaining lever is containerEnv in the user's devcontainer.json, which dl does not own and will not start writing. So this is an upstream change to github.com/skevetter/devpod, not a dl one — carried below as a non-blocking slice whose deliverable is a link, not a diff.

Multiplex devpod ssh — not refused, impossible

devpod's ssh client is Go and reads no OpenSSH config (#389 measured devpod ssh --command at full price with a live master and a matching wildcard block). Multiplexing can only ever help a path that runs OpenSSH. Recorded so nobody re-asks.

Do nothing — rejected

The change is -o flags on an existing argv plus one derived socket path. There is no cheaper thing on this map, the concurrency staircase is a real hazard rather than a latency preference, and doing nothing leaves the prerequisite bug (below) in the tree regardless.

The combination — rejected, and consistently with the route already walked

Nothing survives to combine. This map has refused a fast path plus a fallback at #157 (probe→transfer), #158 (the tar cache), #393 (the status cache) and now twice here. One mechanism.

The prerequisite, and it is a correctness bug

clients/ssh.rs::config_path() hardcodes ~/.ssh/config. devpod 0.26.1 writes its block to SSH_CONFIG_INCLUDE_PATH, else SSH_CONFIG_PATH / $DEVPOD_SSH_CONFIG, else ~/.ssh/config — and only there. On the rig above ~/.ssh/config does not exist at all, so devpod_host_configured answers false, route returns DevpodCommand, and dl silently drops to the devpod transport and loses the pty. #389 noticed this in passing and set it aside; it is load-bearing here, because it means the transport this ticket is speeding up is unreachable on exactly the hosts this repo's own scratch convention and test/conftest.py create. It ships today. It goes first.

The seam's type shape

Two values, and neither is a flag beside the argv.

ControlSocket — the path a master is keyed by. It is derived, so there is no registry, no liveness bookkeeping and no cleanup code: OpenSSH unlinks the socket when the master exits, the master exits when the container dies (#389, four ways), and a stale socket is unlinked by the next client. The digest covers exactly what a master decides on behalf of a later caller and that OpenSSH's own %C does not:

1. the host alias (via %C's remote host/port/user, kept),
2. the SendEnv permit list, and
3. SSH_AUTH_SOCK.

(2) is the whole point. gh::openssh_forwarding(None) returns no args, so a run with no token opens a master with an empty permit list, and the next run with a token reusing it gets an empty GH_TOKEN at exit 0 — reproduced on this rig (GOT=[], rc=0). Keying the socket on the permit list makes that state unrepresentable instead of documented: a client whose permit list differs from the master's cannot find that master. (3) is the same move for #389's other finding, that a reused master pins agent forwarding to whoever opened it. The alternative — declaring SendEnv=GH_TOKEN unconditionally so the list is constant — is refused: it would forward a token that DEVLAUNCH_NO_GH_TOKEN exists to withhold.

Reuse::Multiplexed(ControlSocket) | Reuse::Direct — a two-arm sum, not Option<ControlSocket>. Direct is a real arm with a real cause: a unix socket path must fit sun_path (~104 bytes) and this container has no XDG_RUNTIME_DIR, so the sockets live in their own leaf under devlaunch's cache dir (the LAUNCH_LOCK_DIR precedent: keyed by workspace, XDG_CACHE_HOME-scoped so a scratch run gets scratch sockets, its own directory so the cache's walkers do not read it as a repo) — and a long enough home makes that path unbuildable. A path that will not fit means do not multiplex, never build a master ssh will reject. Both arms produce a valid argv and the same answer; the arms differ in latency only, so this is not a second mechanism and no consumer needs to know which it got.

ControlPersist is a constant, 60s, and not a knob — the DOTFILES_ATTACH_TIMEOUT precedent: getting it wrong costs latency, not correctness. 60s and not 600s because a live master holds a resident devpod ssh --stdio process and a live docker exec per key (observed: three lingering after three masters), and because devpod's docker provider ships an INACTIVITY_TIMEOUT option whose own example is 10m — dl must not be why a user's container never goes idle. Measured at that value: reuse after 40s idle is 22 ms, and past the window OpenSSH has already unlinked the socket and the next trip is an ordinary 1972 ms. No --ssh-keepalive-interval interaction, which #389 listed as unmeasured.

Untouched: ContainerState, SshOutcome, interpret, StderrFilter. This decision does not go near the devpod transport, and ssh::run never needed that recovery — OpenSSH returns the remote status directly, re-confirmed through a master here (requested 7, got 7).

What it does to the spawn-count pins

The counts do not move, and that is deliberate. ControlMaster=auto makes the first trip its own master, so dl spawns no extra process — no pre-warming ssh -MNf, which would have added a spawn and bought nothing. What changes is the argv, and the pins that assert it must be updated to name the three new options. That is the point rather than a chore: #390 asked that a trip which becomes cheap must not become invisible, and a trip that stays a trip in the pinned argv is exactly that. The one new process is OpenSSH backgrounding its own master, which outlives dl by design and is not a spawn dl makes.

How it is tested

At the seams this map already owns, and the first two are the interesting ones:

1. The permit-list key, as a property. Identical (alias, permit list, agent) gives one path; changing only the permit list gives a different one. This is What a devpod ssh trip costs per connection, and whether it can be reused #389's silent-GH_TOKEN failure pinned by a test rather than by a comment, as that research explicitly asked for.
2. The reachability red test. With DEVPOD_SSH_CONFIG naming a config that carries the alias and no ~/.ssh/config present, terminal_for answers Usable. Red on merged main today, which is what makes it a bug fix and not a refactor.
3. The argv pin in clients/ssh.rs and flows/launch.rs's unit tests: ControlMaster=auto, the derived ControlPath, ControlPersist=60, still -t, still SendEnv by name only, alias positional, payload last.
4. The Direct arm: a socket directory that cannot yield a short-enough path produces an argv with no control options at all — and still a working trip.
5. The spawn-count suites, unchanged in count, updated in argv, per the section above.

No test for the refusals; falsification conditions instead, per #158's and #393's precedent, and each is one command:

• Reopen the docker path if devpod starts labelling its containers with the workspace id. Check: docker inspect -f '{{json .Config.Labels}}' on a devpod container, look for a devpod.workspace-shaped key.
• Reopen the telemetry attack if --workspace-env (or any devpod flag or option) starts landing in the container's Config.Env. Check: create a workspace with --workspace-env DEVPOD_DISABLE_TELEMETRY=true and read Config.Env.
• Revisit ControlPersist if a devpod release ties container inactivity to ssh sessions rather than to the workspace.

What is refused, in one place

docker exec as a command fast path; docker inspect as a status fast path (closing #393's deferral); any dl-side attack on the in-container telemetry; multiplexing devpod ssh (impossible); and the probe→transfer merge, which this ticket does not reopen and which stays refused on #151/#157's grounds. One thing is deliberately not decided: whether the non-interactive trips should move onto the same OpenSSH transport. The third breadcrumb measured the parity that would license it (same user, same cwd, --workspace-env values arriving, 100 MB streaming at 4.6s against 7.4s), and it is graduated as its own grilling — because it would make the alias-not-published fallback correctness-critical, and two command-trip mechanisms with different failure vocabularies is the shape this map has refused three times.

Build slices

1. wayfinder:build — dl looks for devpod's ssh config where devpod writes it. Prerequisite, and a bug fix on its own. config_path() resolves $DEVPOD_SSH_CONFIG before ~/.ssh/config; the context-option paths (SSH_CONFIG_PATH, SSH_CONFIG_INCLUDE_PATH) are honoured only from the context options dl has already cached, never by adding a round trip to a warm launch. Terminal::NoAlias splits so "no config anywhere" is distinguishable from "config found, this workspace absent from it", and the notice names the path dl looked in — today the pty transport is lost in silence. Red test as above. CHANGELOG.

2. wayfinder:build — one reusable OpenSSH connection per workspace. Blocked by 1. ControlSocket (derived, digest over alias + permit list + SSH_AUTH_SOCK, under a new ssh-control leaf of the cache dir), Reuse::Multiplexed | Reuse::Direct, ControlPersist constant at 60s, three -o flags in ssh::command_args. Tests 1, 3, 4, 5 above. CHANGELOG naming both the repeat-launch saving and the concurrency one, with the load caveat on every number.

3. wayfinder:build, non-blocking, upstream — report the doubled agent-version exec to skevetter/devpod. Deliverable is an issue (or PR) carrying #389's ProxyCommand decomposition, the buildExistsCheck/detectRemoteAgentVersion reading, and the -e DEVPOD_DISABLE_TELEMETRY A/B, plus the link recorded on #139. ~40% of every trip including the cold ones nothing else here reaches, and the only route to it.

4. wayfinder:grilling — should the probe and the transfer move onto the OpenSSH transport too? Blocked by 2. Carries the parity measurement from the third breadcrumb, the exit-status question (interpret/StderrFilter become deletable on one path and stay required on the other), and the one-mechanism objection. This is where the cold path's remaining ~5s of trip floor gets decided, and it is not decided here.

[blooop]

breadcrumb: resolved. The transport stays OpenSSH over devpod's published alias and gets connection reuse; both provider-specific paths are refused, and the constraint #393 handed down is what refuses the docker inspect one. Four slices named in the resolution, in dependency order: (1) resolve devpod's ssh config where devpod writes it — a shipped bug that makes the pty transport unreachable under DEVPOD_SSH_CONFIG; (2) one reusable connection per workspace, keyed on the SendEnv permit list so #389's silent empty GH_TOKEN is unrepresentable; (3) an upstream report to skevetter/devpod for the doubled agent-version exec; (4) a grilling for whether the probe and transfer join the same transport.