Question
A cold launch spends minutes on a single step and says nothing while it does. What should be on screen during that window?
DEVLAUNCH_TIMING=1 (#140) answers this after the fact — it prints the summary once the launch is over, which is exactly when you no longer need it. There is no live equivalent and no verbosity flag.
What was measured
dl kinisi-robotics/team-tracker@dl-guard-probe on dl 0.29.0, cold (the repo's two cache volumes absent), streaming devpod's output:
11:42:48 creating devcontainer
11:42:51 running postCreateCommands lifecycle hook: .devcontainer/post-create.sh
11:42:52 ✨ Pixi task (ui-install-locked): npm --prefix frontend ci
← 5m 01s, no output at all
11:47:53 added 585 packages in 5m
11:47:53 ✨ Pixi task (db): docker compose up -d db
11:48:01 ✨ Pixi task (migrate): alembic upgrade head
Two consecutive lines five minutes apart. Nothing in between says the launch is alive, which step it is on, or how long that step has been running.
The same launch warm was 21.6s total, with that step taking 5s. So the ratio between a warm and a cold launch of the same branch is ~16x, and a user has no way to tell from the terminal which one they are in.
Worth being clear about attribution: the five minutes are the repo's own postCreateCommand, not devlaunch's work. devlaunch cannot make npm ci faster and should not try. The ask is only that the wait be legible.
What was reported rather than measured
A separate session diagnosing a cold aid kinisi-robotics/team-tracker measured 4m14s from invocation to a live prompt (container up at 0:28, claude launched at 4:14), and reported that in aid's interactive flow the terminal shows nothing after the prompt is accepted — it prints Booting <ws> in the background. Type the prompt for …, takes the prompt, and the next thing to paint is Claude's TUI. That reading came from the binary's strings rather than from captured scrollback, so treat the exact wording as inferred; the silent window itself is not in doubt, and it is what made a healthy launch indistinguishable from a hang.
A compounding factor worth folding in
In --remote-control mode a blocking AskUserQuestion renders wherever the session is being driven from, not on the terminal aid was invoked in. In the run above the session sat on a question for 58s while that terminal showed nothing. So on that terminal a slow launch and a launch waiting on a human look identical — and both look like a hang. Whatever line gets added should be able to say "waiting for you, elsewhere" as well as "still building".
Notes
Related but distinct: #377 is about a failed stage discarding its reason. This is about a succeeding stage saying nothing while it runs. A fix for one does not give the other.
Suggested shape, not a decision: a ticking elapsed line naming the current phase, refreshed in place, e.g. postCreate · npm ci · 2m10s. The binary already links crossbeam's tick channel.
Question
A cold launch spends minutes on a single step and says nothing while it does. What should be on screen during that window?
DEVLAUNCH_TIMING=1(#140) answers this after the fact — it prints the summary once the launch is over, which is exactly when you no longer need it. There is no live equivalent and no verbosity flag.What was measured
dl kinisi-robotics/team-tracker@dl-guard-probeondl 0.29.0, cold (the repo's two cache volumes absent), streaming devpod's output:Two consecutive lines five minutes apart. Nothing in between says the launch is alive, which step it is on, or how long that step has been running.
The same launch warm was 21.6s total, with that step taking 5s. So the ratio between a warm and a cold launch of the same branch is ~16x, and a user has no way to tell from the terminal which one they are in.
Worth being clear about attribution: the five minutes are the repo's own
postCreateCommand, not devlaunch's work. devlaunch cannot makenpm cifaster and should not try. The ask is only that the wait be legible.What was reported rather than measured
A separate session diagnosing a cold
aid kinisi-robotics/team-trackermeasured 4m14s from invocation to a live prompt (container up at 0:28,claudelaunched at 4:14), and reported that inaid's interactive flow the terminal shows nothing after the prompt is accepted — it printsBooting <ws> in the background. Type the prompt for …, takes the prompt, and the next thing to paint is Claude's TUI. That reading came from the binary's strings rather than from captured scrollback, so treat the exact wording as inferred; the silent window itself is not in doubt, and it is what made a healthy launch indistinguishable from a hang.A compounding factor worth folding in
In
--remote-controlmode a blockingAskUserQuestionrenders wherever the session is being driven from, not on the terminalaidwas invoked in. In the run above the session sat on a question for 58s while that terminal showed nothing. So on that terminal a slow launch and a launch waiting on a human look identical — and both look like a hang. Whatever line gets added should be able to say "waiting for you, elsewhere" as well as "still building".Notes
Related but distinct: #377 is about a failed stage discarding its reason. This is about a succeeding stage saying nothing while it runs. A fix for one does not give the other.
Suggested shape, not a decision: a ticking elapsed line naming the current phase, refreshed in place, e.g.
postCreate · npm ci · 2m10s. The binary already links crossbeam's tick channel.