Managed browser sessions
Steel tracks sessions, pages, cookies, and local storage while a connected client supplies browser actions.
Steel Browser
Use Steel to provide a browser session for agent work. Compare the open-source browser runtime with Steel’s hosted MCP and official Skills, keeping service authentication and session costs explicit.
Inspect a hosted browser session
A short extraction checks the full session lifecycle, including cleanup. A useful result records whether the session was released as well as what the page contained.
Configured connection name, source URL, fields, browser-session limit, and maximum session duration.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatYour request for Floatboat
Preview and copy the request. It is not sent automatically from this page.
Reference: Steel Browser https://github.com/steel-dev/steel-browser Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use the named configured Steel connection to extract the requested fields from the supplied URL. Keep concurrent sessions and elapsed duration within the supplied limits; ask for limits if absent. Record the session identifier, save the result, and release the session even after a failed attempt, reporting any cleanup failure. Expected deliverable: A session record with source values, connection evidence, and cleanup status. Include failed steps and unresolved questions when evidence is insufficient.
About Steel Browser
Steel manages browser processes, sessions, pages, and retained state so an existing agent or application can drive them. Its open-source API supports browser connections such as CDP; hosted MCP offers a service-backed coding-agent interface. Creating, reconnecting to, inspecting, and releasing a session are distinct lifecycle operations.
The hosted MCP documentation gives Cursor and Codex configuration and authentication steps. That service is not automatically installed when the open-source browser server is started. The official steel-browser Skill targets Steel cloud browser work; follow the path whose account and runtime you actually have.
The steel-browser repository uses Apache-2.0. Cloud credentials, session time, and connected model services remain separate considerations. For Floatboat, use the documented external-agent MCP or Skill workflow and verify the created session before passing private data or reusing a profile.
How Steel Browser Fits the Browser Workflow
Steel supplies the browser runtime while an agent or script supplies task logic. Browser connectivity, retained session state, and resource release are the infrastructure concerns to resolve.
API and browser connectivity
The open-source service exposes browser APIs and CDP connectivity; hosted MCP provides a service-backed interface for coding agents.
Inspectable session lifecycle
Session IDs connect output and available debugging evidence to a browser lifecycle that ends with release, including failed tasks.
Steel Browser Use Cases
Session provisioning, reusable scripts, failure diagnosis, and runtime placement are different infrastructure decisions. Keep the selected service and evidence visible so a cloud assumption does not silently enter a local deployment.
Supply a browser to an existing agent
Provide a public table URL and a few required columns. Create a session through the configured hosted connection, verify its page, and let the existing host extract values. Return the session ID and sampled source values, then release the session even if the table cannot be read.
Turn a successful lookup into code
Use the official developer guidance to turn a verified browser lookup into a maintained script. Record session creation, connection, extraction, and cleanup, then run the same input again. Reusable code needs explicit error and output handling beyond a successful interactive session.
Diagnose a failed hosted session
Bring the session identifier and the point where the task stopped. Compare logs, traces, or replay evidence available in the selected service to distinguish connection failure from application behavior. Redact credentials and do not infer the cause from a generic timeout alone.
Evaluate browser runtime placement
For a non-sensitive extraction task, compare the operational needs of the open-source server and hosted service. Record which components run where and how the agent connects. A self-hosted runtime and a hosted MCP subscription are different deployment choices, not interchangeable installation commands.
Before Using Steel Browser
The open-source browser server and hosted MCP have different setup requirements. Confirm where the browser will run before configuring the agent.
Cloud or self-hosted choice
Choose the open-source server or hosted service and prepare the corresponding credentials and connection method.
Session lifecycle
Plan session creation, output inspection, and release, including service limits and billing conditions.
Create, Inspect, and Release One Steel Session
Start with a public test URL and a few table fields. This sequence targets a prepared hosted MCP connection; a self-hosted browser API uses its own endpoint and client setup.
Choose the actual service
For hosted MCP, configure the documented service authentication and official cloud-browser guidance. For a self-hosted server, select its API/CDP connection. Confirm the tools or endpoint response before creating a session; starting the open-source container does not create hosted MCP access.
Create and identify the session
Create a session through the selected service and retain its identifier and connection information. Open the public URL and confirm its title or content. Reconnect to that same session for dependent operations instead of silently creating a browser with different state.
Extract and inspect a sample
Read the requested fields and compare a representative value with the page. Save source URL, session ID, missing fields, and any request or replay evidence available for that service. Report navigation failure separately from a valid empty result.
Release and report the final state
Release the task session even if extraction failed. Confirm release through the selected API response or service session view. If cleanup cannot be confirmed, include the session ID and unresolved state so the operator can find the remaining resource.
Related Software Projects
Compare the workflows, operating requirements, and source licenses of these projects.
Steel Browser FAQ
Is Steel an autonomous browser agent?
The browser infrastructure supplies sessions and connectivity. An agent or application supplies task reasoning and actions; the hosted MCP and Skills are ways to connect that existing host.
Does running steel-browser provide hosted MCP?
No. The open-source server and Steel’s hosted MCP are distinct deployment surfaces. Use the service documentation for its authentication and client setup rather than assuming a local container supplies them.
Which Skill should I choose?
The official repository distinguishes steel-browser for live work, steel-developer for code, and steel-session-debugging for failed runs. Choose the job first instead of installing every instruction indiscriminately.
Can Cursor, Codex, and Floatboat connect?
The hosted MCP documentation lists Cursor and Codex. Floatboat can use the corresponding MCP path with the service’s account and authentication requirements; it is not a bundled browser entitlement.
Does Apache-2.0 include free cloud sessions?
No. The source license governs the repository code. Hosted browser sessions, service limits, and model use follow their own terms, even when an open-source client connects to them.
What if extraction fails after session creation?
Retain the session ID, separate navigation/connection errors from missing data, and inspect evidence available from that service. Release the session on failure as well; explicitly report an unresolved release so the operator can locate the remaining resource.