Give a harness its argv back

[edwin-zvs]

The bug

Harness argv forwarding — construct new <harness> <args...> — is completely broken. Passing any harness argv kills the session with spawn adapter for <harness>, about five seconds in.

Every documented example fails on main:

invocation	source	main
construct new claude --model opus	docs/harnesses.md:51	❌
construct new --prompt "fix tests" claude --permission-mode acceptEdits	docs/harnesses.md:50	❌
construct new --title "server logs" shell -lc 'tail -f server.log'	spec 0120's own example	❌
construct new shell (no argv)	—	✅

This violates spec 0120, which is accepted and mandates exactly this forwarding.

Root cause

The daemon appended the session's args to the adapter process's dispatch command line, in addition to sending them in the start params:

let combined_args = { let mut a = adapter_cfg.args.clone(); a.extend(params.args.clone()); a };

Every built-in adapter is dispatched as construct __adapter <name>, which accepts no arguments:

$ construct __adapter shell -lc 'echo hi'
error: unexpected argument '-l' found
Usage: construct __adapter shell [OPTIONS]

So the adapter process died at startup, never bound its socket, and the daemon's 5s connect_with_retry expired — surfacing as a spawn failure that named neither argv nor the flag responsible.

The args were already reaching the adapter correctly over the socket (every adapter does args.extend(params.args.clone()) from start_params), so the command-line copy was pure corruption. config.toml already calls that field "dispatch args"; now it only carries those — at create and at respawn, which had the same bug.

How it was found

Chasing why construct new shell --no-tui failed. Construct's own flags go before the harness (spec 0120's positional grammar), so --no-tui landed in harness argv — and hit this.

Also fixed

• scripts/smoke.sh — passed --cwd after the harness, so it went to the shell and the session was created in the wrong directory; had no --no-tui, so it could never capture the id it assigns to $SID; and a fixed sleep 0.4 lost the startup race, failing at the first ping. Now runs green end to end, in the right sandbox.
• .claude/skills/verify/SKILL.md — documented construct new shell "" --no-tui, the broken form that led here. Corrected, with the ordering rule spelled out.
• specs/0120 — records the invariant that was violated: forwarded argv belongs to the session and travels in its start params; an adapter's own command line is dispatch only.

Verification

New crates/e2e/tests/harness_argv.rs, all passing:

test a_session_with_harness_argv_starts ... ok
test harness_argv_is_what_the_harness_runs ... ok
test a_prompt_still_runs_without_argv ... ok
test result: ok. 3 passed; 0 failed

The middle one asserts the argv is what the harness actually ran, by matching a marker in the session's PTY log — not merely that create returned an id.

Manually against a fresh daemon, every previously-broken form now works, including survival across a daemon restart (exercising the respawn path), and scripts/smoke.sh exits OK with the session in /private/tmp/smoke-after.

Note for review

This is a behavior change for custom/plugin adapters: an external adapter binary that relied on receiving session args on its command line rather than from start_params would stop seeing them there. Every built-in adapter reads params.args, and the config field is documented as dispatch args, so this looks like the intended contract — but worth a second opinion if any out-of-tree adapter depends on the old shape.

construct new shell --no-tui still doesn't suppress the TUI: --no-tui goes to the shell, per spec 0120's deliberate grammar. It now fails as a shell argument error rather than an opaque spawn error. Changing that would mean changing the grammar, which this PR does not do.

Binaries

Touches crates/daemon (the fix) and crates/e2e (tests) — the daemon is embedded in the single binary:

/Users/moon/construct/.claude/worktrees/cli-flag-order/target/debug/construct