Browser-Agent Workspace, Pre-auth, and Reuse
How authors use the browser-agent workspace to sign into a site inside an embedded browser, finish setup, and reuse the saved browser state in later browser-aware work.
Browser-Agent Workspace, Pre-auth, and Reuse
Where you see this in the app
This page explains the dedicated browser workspace template that authors can open from a post’s workspace area.
It matters when you want to sign into a third-party site inside a workspace browser first, then reuse that saved browser state later from Codex or automation runs.
What the browser-agent workspace is for
The browser-agent workspace is a specialized workspace template for browser-based tasks.
Its job is simple:
- open an embedded browser inside the workspace,
- let you log into the target service there,
- save that login state for your account in this environment,
- make that saved state available to later browser-aware work in the same workspace ecosystem.
This is useful when the later task depends on being signed into a service first.
Examples include:
- email or productivity tools,
- social or publishing tools,
- account dashboards that require your own session,
- browser-driven flows that should continue later without repeating login every time.
Start pre-auth and sign in
The browser panel includes a start URL field and a Start Pre-auth action.
From an end-user perspective:
| Control | What it means |
|---|---|
| Start URL | The site the embedded browser should open first |
Start Pre-auth | Launch the embedded browser so you can sign in manually |
| Live view | The interactive browser surface you use for login and setup |
This login happens inside the embedded browser itself, not inside the chat.
That is the important trust model for this feature:
- type passwords, MFA codes, and other sign-in actions into the browser page itself,
- do not treat the chat as the place to hand over account credentials.
Finish setup, cancel, and disconnect
The browser workspace separates three different actions because they mean different things.
| Action | What it does |
|---|---|
Finish Setup | Mark the browser profile as ready for later reuse |
Cancel Pre-auth | Stop the current setup session without keeping that session active |
Disconnect Profile | Clear the saved browser profile so you can start fresh later |
Use Finish Setup after the sign-in or setup work in the embedded browser is complete.
Use Cancel Pre-auth when the current setup attempt should stop without continuing.
Use Disconnect Profile when you want to remove the saved browser state entirely and begin again from a clean browser profile.
What a shared browser profile means
Shared browser profile means the saved browser state belongs to your account in this environment, not only to one temporary browser tab.
In plain English, that means:
- you do not have to re-create the browser login state every time,
- later compatible browser work can reuse the saved state,
- the saved state is tied to your author workspace usage in the same environment.
It should not be thought of as a public or post-level asset.
It is your saved browser state for workspace use, not something buyers or random viewers are meant to inherit.
How later Codex and automation reuse works
After setup is finished, later browser-aware tasks can use the saved browser profile instead of starting from a completely unsigned-in browser.
The end-user mental model should be:
- browser-agent workspace: prepare the browser state,
- Codex or automation run: reuse that prepared state for later work.
This does not mean every Codex task automatically becomes browser-driven.
It means browser-aware tasks now have a reusable signed-in starting point when that workflow is supported.
Limits and expectations
This first version should be understood with a few boundaries in mind.
| Expectation | What users should assume |
|---|---|
| Author workflow | This feature is for the post author in an edit-mode workspace |
| Manual setup | The initial sign-in is meant to be done manually in the embedded browser |
| Environment-specific state | A saved browser profile in one environment should not be assumed to appear in every other environment |
| Session expiry | Third-party sites can still expire sessions later and require another login |
If a later browser-driven task stops behaving like you are signed in, the most likely explanation is that the target service expired the saved session and you need to run the setup flow again.
Common questions and troubleshooting
The workspace says a browser session is already active
Usually that means an earlier setup session is still considered active.
Try the browser controls in this order:
Cancel Pre-authif the current setup attempt should stop,Disconnect Profileif you want to clear the saved browser state entirely,- start pre-auth again after the workspace reflects the updated state.
I finished setup, but a later run seems signed out
Treat that as a normal expired-login case first.
Third-party services can sign you out, rotate cookies, or ask for more verification later. Re-run the browser setup flow when that happens.
Should I put account credentials into chat?
No. Enter sign-in information inside the embedded browser page itself.
Is this the same thing as the normal live preview?
No. The browser-agent workspace is a dedicated browser-oriented workspace surface. It is meant for browser login and later reuse, not only for previewing a site or app.
Related docs
Related docs
See it in action
Previous
Workspace Upload Targets and ZIP Merge Behavior
How the Upload tab works in edit mode, what Workspace project vs Static preview site mean, how target paths are resolved, and what ZIP merge actually does.
Next
Workspace Terminal, Helix, and Codex Tool Access
How the live preview and embedded workspace tools differ, what read-only viewer mode means for Terminal, Helix, and Codex, and how sessions and Codex shortcuts fit into edit-mode work.