This playbook is optimized for agents and automation loops that invoke
steel browser commands repeatedly.
Use a named session and keep it constant for the whole workflow:
steel browser start --session "$SESSION_NAME"
steel browser open https://example.com --session "$SESSION_NAME"
steel browser snapshot -i --session "$SESSION_NAME"
steel browser stop --session "$SESSION_NAME"Why:
- avoids accidental new sessions between commands.
- allows cross-process reattach with the same
--session <name>. - keeps recovery steps predictable.
From steel browser start output:
id: canonical session identifier.mode:cloudorlocal.name: session alias (when provided).live_url: viewer URL (when available).connect_url: display-safe URL; sensitive query values are redacted.
Do not assume connect_url contains usable raw credentials.
Likewise, steel browser sessions returns display-safe connectUrl fields.
It emits compact metadata by default; add --raw for full session payloads.
If a downstream tool requires an auth-bearing CDP URL, construct it from
id + environment key:
wss://connect.steel.dev?sessionId=<SESSION_ID>&apiKey=$STEEL_API_KEYThis keeps secrets in env/config rather than CLI logs.
Check active context:
steel browser sessions
steel browser live
# or: steel browser live --session "$SESSION_NAME"Cloud auth verification:
steel configSelf-hosted runtime verification:
steel dev start
steel browser start --local --session "$SESSION_NAME"Missing browser auth...: authenticate (steel login) or exportSTEEL_API_KEY.Failed to reach Steel session API ...: check endpoint flags/env and runtime availability.- Existing session not reused:
verify exact
--sessionspelling and same mode (cloud/local). - Stale state:
steel browser stop --all, then start a new named session.
- never print
STEEL_API_KEYdirectly. - treat
connect_urlas non-secret display output only. - prefer session IDs and named sessions in logs for reproducible debugging.