Workspace

Documentation Index

Fetch the complete documentation index at: https://docs.frontic.com/llms.txt

Use this file to discover all available pages before exploring further.

A Studio workspace is the isolated environment where a job runs. It’s a sandbox with your repository at a feature branch, a running dev server for the preview, and the Git state the Studio chat edits against. Every job has its own workspace; two workspaces don’t share state, so multiple jobs can run in parallel without interfering with each other. The workspace is what you interact with on the right side of Studio, through two main panels:

• Preview — a live-rendering view of the code, updating as files change
• Changes — the Git state of the workspace (new files, modified files, deleted files, branch state)

Between them, you have a full picture of what’s happening without ever leaving the admin app.

​

The sandbox environment

When you create a job, Studio stands up a fresh workspace for it:

• a sandbox with your repository at the base branch you picked, with a new feature branch created for the job
• a running dev server that the Preview panel renders from
• isolation from every other workspace in the project — each has its own branch, its own sandbox, its own running processes

The workspace is ephemeral in the sense that it’s scoped to the job, but it persists as long as the job is open. Exit the job and come back tomorrow — chat history, preview state, and uncommitted changes are all intact. Archiving a job tears the workspace down: the running dev server, the preview, and any uncommitted file changes go with it. Studio saves the conversation transcript before the teardown, so unarchiving rebuilds a fresh workspace at the same base branch and replays the chat history into it. Anything that wasn’t committed and pushed before archiving is gone.

​

The Preview panel

The Preview panel is a live-rendering view of the code in the workspace. As files change — through the agent’s edits or through your own — the preview updates. It talks to Frontic via the generated Client SDK, which Studio points at develop — the live stack state — so the preview reflects what you’re building on the stack side too. Studio keeps the SDK in sync as stack config changes, no manual regenerate step.

​

What you can do in Preview

​

What to do in Preview

Don’t only scan the preview for visual problems. Click through the UI the way a user would:

• Type in a search box
• Click a filter and make sure the results update
• Navigate between pages and confirm the URL and content both change
• Hit the back button
• Submit a form
• Check the mobile layout with the viewport toggle
• Test an empty state (filter everything out)
• Test an error state (intentionally trigger a 404)

Real UI has edge cases the agent can’t predict from the prompt alone. The preview is where you find them.

​

What the agent does in Preview

The same panel is the agent’s testing harness. While the agent is editing code, it inspects the running preview the way a human would:

• Visual checks. The agent captures screenshots of the rendered preview to confirm a visual change actually landed, navigates between pages to check secondary states, and catches layout regressions you’d otherwise have to flag in chat.
• Browser-level diagnostics. When something behaves wrong, the agent reads console output, inspects network activity, and runs targeted JavaScript probes against the running page to trace the cause. Say “the price isn’t showing” and you’ll often see the agent surface the failed request or the broken selector in the next message instead of asking you to dig.

You don’t drive any of this — it happens as part of normal task execution. The point is that the agent doesn’t hand off broken code: it’s seen the result before claiming a task is done.

​

Preview limitations

• It’s a dev build, not a production build. Bundle splitting, asset optimization, real SSR in some frameworks — those only happen in a production build. The Preview is a fast-iteration dev server, not a staging environment.
• Share the preview URL with teammates only. The workspace sandbox isn’t sized for wider traffic, so for stakeholders, customers, or anyone outside the team, use your hosting platform’s PR deploy URL instead.
• The preview suspends when idle. The sandbox sleeps after inactivity and cold-starts on the next request — opening the preview after a break may take a moment to come back.
• External image domains may block the preview. Some shop image CDNs disallow cross-origin requests (no permissive Access-Control-Allow-Origin) or enforce a Referrer policy that rejects requests not coming from the production storefront. The preview runs from a Frontic-hosted sandbox URL, so those policies treat its requests as untrusted and the images don’t render. The fix lives on the image domain — allow the sandbox origin (or * during development) on Access-Control-Allow-Origin, and either relax the Referrer policy or allow the sandbox origin to send a Referer your CDN accepts.

​

The Changes panel

The Changes panel is the workspace’s equivalent of git status + git diff. Every file change the Studio chat makes shows up here, diffable, reviewable, and ready to commit.

​

What it shows

• New files — files the agent created, with full content
• Modified files — line-by-line diffs against what was in the file before
• Deleted files — files the agent removed, with the content that was deleted
• Branch state — how many commits ahead of the base branch the workspace is, whether anything is unpushed, whether the branch has diverged from remote
• Uncommitted changes — the current working tree delta since the last commit

​

Reviewing diffs

Every diff should get eyes before it’s committed. The Studio chat is usually right, but it’s not always right, and the cost of catching a wrong edit in review is a tenth the cost of catching it after merge.

​

A typical flow

Here’s what day-to-day work in a workspace looks like — chat on the left, Preview and Changes on the right, you moving between them:

​

Parallel workspaces

You can have multiple jobs open at the same time, each in its own workspace, working against the same repository on different feature branches. Studio handles the Git isolation — each workspace has its own branch, its own sandbox, its own running processes. Two agents (or you and an agent) can work on unrelated tasks without collision. Where this gets tricky: coupled changes. If one job depends on a change another hasn’t merged yet, its branch is missing that work. The usual fix is to finish the dependency first, merge it, and rebase the dependent job onto the updated base. Studio doesn’t do anything magical to resolve this — it’s Git.

​

What’s not in the workspace

A few things a Studio workspace deliberately doesn’t include:

• A full editor. Workspace editing happens through the Studio chat, not a local text editor. If you need to edit a file by hand, pull the branch locally and work in your own editor.
• A terminal. You can’t run arbitrary shell commands in a Studio workspace. The agent runs commands through its tool calls, but there’s no open shell. For arbitrary terminal work, pull the branch locally.
• A debugger. The preview is a browser window; you can use the browser’s devtools on it, but there’s no integrated debugger for the code itself.

The workspace is focused on the chat/preview/review loop. Anything deeper is a sign the work should happen in your own editor — and that’s supported directly, because the branch is a real Git branch you can clone at any point.

​

Related