Steel CLI

Browser infrastructure for AI agents, from your terminal.

The Steel CLI gives any AI agent (Claude, Cursor, Browser Use, or your own) a production-grade cloud browser: markdown-first scraping, long-running sessions, stealth, residential proxies, automatic CAPTCHA handling, and credential injection. One binary, cloud or self-hosted.

# Install, then interactively log in and install agent skills
curl -fsS https://setup.steel.dev | sh

# Scrape a page (agent-ready markdown)
steel scrape https://example.com

Why Steel CLI

• Agent-native. Markdown-first output, steel describe for machine-readable command introspection, shell completions, and ready-to-install skills for Claude Code, Cursor, OpenCode, and Codex.
• Long-running sessions. 24-hour browser sessions, reusable named profiles, persistent auth context. Built for agents that actually live: deep research, async workflows, overnight jobs.
• Framework-agnostic. First-class support for Claude Computer Use, OpenAI Computer Use, Gemini Computer Use, Browser Use, Playwright, Puppeteer, Selenium, Stagehand, CrewAI, Magnitude, Notte, Agno, and AgentKit.
• Cloud or self-hosted. Fully open source. Use managed infrastructure at steel.dev, or run the Steel Browser stack yourself with steel dev or Docker.
• Pro browser features. Managed residential proxies, stealth mode, automatic CAPTCHA solving, stored credential injection. Everything a real-world agent needs.

Links

• 📖 Docs: guides, recipes, API reference
• 🧪 Cookbook: runnable examples across Python, Node, and every supported framework
• 💬 Discord: community, feedback, roadmap
• 🐙 GitHub: source, issues, releases

Install

curl -fsS https://setup.steel.dev | sh

The installer drops a single binary into ~/.steel/bin, updates your shell's PATH, and auto-generates shell completions for bash, zsh, and fish.

Alternatives:

• Download from GitHub Releases
• cargo install steel-cli

After install, either restart your shell or run export PATH="$HOME/.steel/bin:$PATH".

Device login

steel login shows a short code and authorization URL; approve in a browser on any machine. steel login --resume continues the saved request after interruption. Non-interactive commands return promptly while approval is pending. Repeat steel init after approval to continue setup. API keys remain supported.

Credentials are used in this order: STEEL_API_KEY, then a device login, then an API key saved by an older steel login. While a saved API key is the active credential, steel login reports it and does not start device authorization; run steel logout first to switch to device login.

The defaults are production values. These settings may be independently overridden for a test environment; an audience is an exact resource identifier, not an API URL:

Setting	Default
STEEL_AUTH_ISSUER	https://auth.steel.dev
STEEL_AUTH_AUDIENCE	https://api.steel.dev
STEEL_API_URL	https://api.steel.dev/v1

Use a separate STEEL_CONFIG_DIR for testing. Auth context, pending authorization and credentials are saved privately in its auth.json; credentials are never silently retargeted when an override changes: STEEL_API_URL or --api-url pointing elsewhere fails without sending the token. Device access tokens use Bearer authorization and refresh automatically; API keys still use Steel-Api-Key. Product API requests never follow redirects. The configured local runtime (--local, browser.apiUrl) never receives a device login issued for another API; it gets STEEL_API_KEY or a saved API key if present, as before. Connection URLs are shown with only sessionId visible.

steel doctor --preflight checks product API access. steel logout revokes the saved refresh grant, and deletes local state only after revocation succeeds. Revocation ends the grant; access JWTs already issued stay valid until they expire. A login without a refresh token cannot be revoked by the CLI: revoke the device in your account, then run steel logout --local-only, which forgets local state without contacting the server. Do not paste or log access/refresh tokens, device codes or signed connection URLs.

Shell Completions

Shell completions are installed automatically by install.sh. To regenerate or install manually:

# Bash (user-local)
steel completion bash > ~/.local/share/bash-completion/completions/steel

# Zsh (ensure a writable dir is in $fpath, then reload)
steel completion zsh > "${fpath[1]}/_steel"

# Fish
steel completion fish > ~/.config/fish/completions/steel.fish

# PowerShell (append to $PROFILE)
steel completion powershell | Out-String | Invoke-Expression

Supported shells: bash, zsh, fish, powershell, elvish.

Command Overview

Group	Commands
Onboarding	init, forge
Browser lifecycle	browser start, browser stop, browser sessions, browser live
Browser actions	browser open, browser snapshot, browser click, browser fill, browser batch, …
Browser profiles	profile import, profile sync, profile list, profile delete
API tools	scrape, screenshot, pdf
Local runtime	dev install, dev start, dev stop
Credentials	credentials list, credentials create, credentials update, credentials delete
Account and utility	login, logout, config, doctor, cache, update, completion

Full flags and schemas: CLI reference.

How steel browser Works

Each steel browser action is one request to the session's commands API. The browser engine runs inside the Steel session next to Chrome, so the CLI keeps no process running between commands.

steel browser open https://example.com
steel browser snapshot -i
steel browser click e5 --diff
steel browser batch "fill e3 Seoul" "click e7" "snapshot -i"

• The default session starts on first use. Use --session <name> for more, or --session <session-id> to drive a session created elsewhere. steel browser stop --all leaves sessions created elsewhere running.
• Sessions are released after 10 minutes without commands (steel browser start --inactivity-timeout <ms>).
• A retried command never runs twice. Run the same command again after a lost response to get the stored result.
• Self-hosted Steel Browser serves these commands only with ENABLE_COMMANDS_API=true. steel dev start does not set it yet.

See the Steel browser reference and the command catalog for details.

Endpoint Resolution

Every command that calls the Steel API uses one URL, chosen in this order:

1. --api-url <url>
2. --local: browser.apiUrl in ~/.config/steel/config.json, or http://localhost:3000/v1
3. STEEL_API_URL
4. With no explicit override and an active device credential, the API URL saved with that device login
5. Otherwise, https://api.steel.dev/v1

URLs on steel.dev are Steel Cloud and require authentication through device login or an API key. Any other URL is treated as self-hosted. An explicit STEEL_API_KEY takes precedence over device login and does not activate the saved-device-endpoint fallback.

Output and Runtime Notes

• steel scrape prints markdown by default for token efficiency; use --json for the full API response.
• steel browser start prints a display-safe connect URL with sensitive query values redacted.
• Output is text by default, including when piped. Pass --json for machine-readable output.

Documentation Map

Primary docs:

• Docs index
• Generated CLI reference

Reference docs:

• References index
• Steel CLI reference (high-level)
• Steel browser reference (modes + contracts)
• Steel browser commands
• Agent troubleshooting playbook

Agent skills:

• Steel Skills catalog
• Steel Agent Skills docs

---

Licensed under MIT.