Context
While building the website "Copy Prompt for Agent" CTA (prompt being added at docs/agent-prompt.md), we audited the CLI's agent-onboarding surface and found several leftovers worth revisiting. Filing as one issue so the history isn't lost — can split into separate issues if preferred.
1. src/commands/init/init_agent_guide.md is orphaned dead code
- b865514 (
feat: one-command onboarding with 'steel init') shipped steel init --agent = print this guide and exit ("authoritative setup instructions" per the original flag docs). install.sh --agent was wired to deliver it (5c93d80).
- 140692b (
feat: simplify --agent flow) removed the include_str! and repurposed --agent to mean "auto-accept prompts". The ~150-line guide has had zero references since — still true on main today.
Decide: revive it (print-and-exit --agent, move auto-accept to e.g. --yes) or delete the file. If revived, the content needs a rewrite: it predates the steel-dev/skills install flow, and it claims the auth link works "from any device", which is incorrect — the OAuth callback goes to 127.0.0.1, so cross-device sign-in cannot complete.
2. install.sh docstring describes the removed behavior
The flag docs still say --agent "print[s] the onboarding guide to stdout", and the comment above the init invocation says "Agent mode just prints the onboarding guide to stdout, which needs no TTY". Neither has been true since 140692b. Should be synced whichever way item 1 lands.
3. Onboarding attribution never reaches telemetry
install.sh --from <agent> exports STEEL_ONBOARDING_FROM, but the only consumer is a status!() print in init. login_completed (src/commands/login.rs) fires with empty properties — and since login typically happens in a later shell than the installer, the env var is gone by then anyway. If we want to measure which agents/CTAs drive activation, the value needs to be persisted at install/init time (e.g. into config) and attached to login_completed / first-session events.
4. Login's 5-minute foreground wait vs agent shell timeouts
steel login blocks in the foreground waiting up to 5 minutes on a localhost callback. Coding agents commonly run shell commands with ~2-minute default timeouts, which kills the listener mid-auth. The website agent prompt works around this with "run with a ≥6-minute timeout or in the background", but a pollable/detached flow would be more robust (cf. Kernel's kernel login + poll kernel auth pattern) — and a device-code-style flow would also unblock remote/sandboxed environments (Codespaces, hosted agent sandboxes) where the localhost callback can never complete and the only answer today is manually setting STEEL_API_KEY.
Context
While building the website "Copy Prompt for Agent" CTA (prompt being added at
docs/agent-prompt.md), we audited the CLI's agent-onboarding surface and found several leftovers worth revisiting. Filing as one issue so the history isn't lost — can split into separate issues if preferred.1.
src/commands/init/init_agent_guide.mdis orphaned dead codefeat: one-command onboarding with 'steel init') shippedsteel init --agent= print this guide and exit ("authoritative setup instructions" per the original flag docs).install.sh --agentwas wired to deliver it (5c93d80).feat: simplify --agent flow) removed theinclude_str!and repurposed--agentto mean "auto-accept prompts". The ~150-line guide has had zero references since — still true on main today.Decide: revive it (print-and-exit
--agent, move auto-accept to e.g.--yes) or delete the file. If revived, the content needs a rewrite: it predates the steel-dev/skills install flow, and it claims the auth link works "from any device", which is incorrect — the OAuth callback goes to127.0.0.1, so cross-device sign-in cannot complete.2.
install.shdocstring describes the removed behaviorThe flag docs still say
--agent"print[s] the onboarding guide to stdout", and the comment above the init invocation says "Agent mode just prints the onboarding guide to stdout, which needs no TTY". Neither has been true since 140692b. Should be synced whichever way item 1 lands.3. Onboarding attribution never reaches telemetry
install.sh --from <agent>exportsSTEEL_ONBOARDING_FROM, but the only consumer is astatus!()print ininit.login_completed(src/commands/login.rs) fires with empty properties — and since login typically happens in a later shell than the installer, the env var is gone by then anyway. If we want to measure which agents/CTAs drive activation, the value needs to be persisted at install/init time (e.g. into config) and attached tologin_completed/ first-session events.4. Login's 5-minute foreground wait vs agent shell timeouts
steel loginblocks in the foreground waiting up to 5 minutes on a localhost callback. Coding agents commonly run shell commands with ~2-minute default timeouts, which kills the listener mid-auth. The website agent prompt works around this with "run with a ≥6-minute timeout or in the background", but a pollable/detached flow would be more robust (cf. Kernel'skernel login+ pollkernel authpattern) — and a device-code-style flow would also unblock remote/sandboxed environments (Codespaces, hosted agent sandboxes) where the localhost callback can never complete and the only answer today is manually settingSTEEL_API_KEY.