aid reads DEVLAUNCH_AID_AGENT with the call osext exists to replace

[blooop]

Finding

aid/src/main.rs:92 reads DEVLAUNCH_AID_AGENT with the call osext exists to replace:

std::env::var(rewrite::AGENT_ENV_VAR).ok().as_deref(),

osext.rs:11-13 names the hazard: std::env::var(..).ok() reports a non-UTF-8 value as unset. So a DEVLAUNCH_AID_AGENT holding undecodable bytes silently selects the default agent instead of refusing with UnknownAgentInEnvironment — the refusal rewrite::default_agent (aid/src/rewrite.rs:244) exists to give.

This is the same class as the DEVLAUNCH_NO_TTY divergence fixed in b52f4fa, with a milder consequence: a wrong agent rather than an inverted opt-out. Filed rather than fixed alongside it because the fix is not local — aid depends on dl and not on devlaunch-core (deliberately: aid/src/main.rs:20-26), so the correct reader has to be re-exported one more level, and that is surface churn worth deciding on rather than smuggling into a bug fix.

Shape

Either re-export the reader through dl the way shell and python_repr already are (dl/src/lib.rs:44,51), or have rewrite take the already-decoded value and let dl do the reading. The second keeps aid's dependency story intact.

While there: osext is still pub(crate) apart from the one wrapper b52f4fa exposed. Every future binary-side environment read has the same trap set for it, and the general fix is to make osext binary surface — the tier clients, domain and flows already sit in.

Proving it

DEVLAUNCH_AID_AGENT=$'\xff' should refuse by name, not fall through to the default.

[blooop]

breadcrumb: built test-first in #413 (fix/aid-agent-env, off main), in review, not merged.

Red first. aid/tests/rewrite.rs gained an_agent_name_that_does_not_decode_is_refused_rather_than_read_as_unset, which spawns the binary with DEVLAUNCH_AID_AGENT set to the raw byte \xff. Before the change it failed with left: Some(0) / right: Some(1) and stderr showing aid -> dl ... claude --dangerously-skip-permissions hi plus the ssh attach — the bug printed verbatim: exit 0, default agent, workspace opened. After it, exit 1 and DEVLAUNCH_AID_AGENT='\u{fffd}' is not a known agent. Choose one of: claude, codex, gemini., with no devpod call. The test lives at the process boundary because that is the only place the bug is: rewrite::default_agent was always correct, so a unit test of it is green before the change.

Shape chosen: the first of the ticket's two, one item wide. osext::env_str becomes binary surface, dl re-exports it beside shell and python_repr, and aid calls dl::env_str. The ticket's second option — rewrite taking an already-decoded value — is already how parse_aid_args is written; the reading, not the signature, was the bug, so that option collapses into "somebody has to hand aid the decoded value", and dl is the only crate aid can be handed anything by. aid's single-dependency rule is untouched.

The pub(crate) question, answered narrowly. osext is now pub for env_str alone: strip, home_dir and temp_dir were pub inside a pub(crate) mod and are demoted to pub(crate), so the module going public promotes exactly the one function with a caller outside the crate. That is the shape json already has (pub for JsonKind, writers pub(crate)). #406's "not yet specified" note asks whether osext should become binary surface wholesale and says it wants a second caller first — this is deliberately not that answer, and leaves the note standing with one instance now spent.

Gate: cargo test --workspace, clippy --locked --all-targets -D warnings, fmt --check all green. One intermediate full run hit dl --test picker::what_is_typed_... on a pty echo race ("> wayfind" vs "> wayfinder"); it passes alone 3/3 and the whole suite is green on the next run of the same code — #401's family, not this diff.

public-api.rest.txt gains two rows by hand (pub mod devlaunch_core::osext and the env_str signature) since cargo-public-api needs nightly and cannot be installed here; CI's regeneration is authoritative.

[blooop]

breadcrumb: PR #413 opened. Its osext::env_str exposure falsified a doc claim in #407; reconciled there in eb8a29d rather than left to rot.

[blooop]

breadcrumb: wf-review on #413 — approve, no blocking findings. One confirmed defect for a follow-up commit: making osext public leaves three dead intra-doc links (strip/home_dir/temp_dir) in the module doc it promotes. Snapshot rows confirmed by CI's regenerate-and-diff; the new test confirmed red on the pre-change main.rs. #413

[blooop]

Follow-up commit on #413: 4f925e5 clears the three rustdoc::private_intra_doc_links warnings the review found in osext's module doc, which appeared because making the module pub turned that doc into public documentation while strip, home_dir and temp_dir stayed pub(crate). Link syntax dropped, prose unchanged.

The review's alternative -- pub(crate) mod osext plus pub use osext::env_str; at core's root -- was weighed and not taken. cargo doc -p devlaunch-core --no-deps emits 112 of these warnings crate-wide, so the re-export would remove three of them and leave the pattern everywhere else; it would also cost the osext:: qualifier in the public path, and it pre-answers #406's question about whether the rest of the module follows env_str out. Recording it here because #406 may want the other shape once a second caller exists.

No public surface change, so public-api.rest.txt is untouched. Ticket stays open -- not merging.

[blooop]

Breadcrumb: #413 was carrying this fix with no CHANGELOG entry. Added one on fix/aid-agent-env (4e200b7), under a new ### Fixed in ## [Unreleased], naming the user-visible symptom -- an undecodable DEVLAUNCH_AID_AGENT read as unset, so the default agent started and the workspace opened.

CHANGELOG only; no code touched, nothing closed here.

[blooop]

Shipped in PR #413, taking this ticket's first shape: dl re-exports env_str (pub use devlaunch_core::osext::env_str) and aid reads DEVLAUNCH_AID_AGENT through it, with a process-boundary red test proving an undecodable value now refuses by name instead of selecting the default. The "make the osext surface public wholesale" aside was deliberately answered narrowly (only env_str), consistent with #406's standing note.