Workspace Preview Embed vs New-Tab Fallback

Where you see this in the app

This page documents what happens when a workspace session starts successfully but the app does not keep the experience inside the inline embedded preview.

Users may see a message such as Workspace session ready followed by the workspace opening in a separate browser tab.

Embedded preview vs separate tab

The preferred experience is the inline embedded workspace preview inside the post page.

But the app can also fall back to a separate browser tab when the inline embedded mode is not available for that session.

From an end-user perspective, both paths can still represent a successful workspace launch.

Workspace session ready

Workspace session ready does not guarantee that the preview will stay inside the page.

It only guarantees that the session itself was created successfully.

This distinction matters because users can misread a new-tab launch as a failure when it is really a working fallback.

When the app opens a new tab

The app uses the separate-tab fallback when it has a valid redirect target but does not have what it needs to keep the current page in embedded mode.

That is why the UI can say:

Workspace opened in a new tab as embedded mode is unavailable.

Users should interpret that as:

• the session exists,
• the workspace can still be used,
• only the inline embedding path is unavailable for this launch.

What this does and does not mean

This fallback does mean:

• the workspace launched,
• a preview path exists,
• continuing in a new tab is supported.

It does not necessarily mean:

• the workspace is broken,
• the controller failed,
• the user lost access.

If the workspace also shows an explicit launch error, that is a different problem from a successful new-tab fallback.

Related docs

• Workspace start errors, capacity, and credits
• Workspace runtime, preview, and publishing
• Workspace terminal, Helix, and Codex tool access