> ## 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. # Workspace A Studio **workspace** is the isolated environment where a [job](https://docs.frontic.com/studio/frontic-studio.md) 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 job title The job's title sits in the breadcrumb at the top of the page. * **Rename it:** use the pencil next to the title. Clicking the title itself opens the job list below. * **Suggested titles:** a new job starts **Untitled**, and the agent names it after your first prompt. Once a job has a name, the agent never changes it. When it thinks of a better one, a sparkle appears next to the title, and you can apply the suggestion or ignore it. * **Switch jobs:** click the title to open a searchable list of the project's jobs that aren't archived. Each entry shows the owner's avatar, the branch and repository or the template, and when the job was created. **Create job** at the bottom opens the new-job dialog. ## 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 **project credential vault**, injected as environment variables - anything you stored under [Studio Settings → Credentials](https://docs.frontic.com/studio/settings.md#credentials) is available to the running code from the first request 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. If the agent hits code that needs a secret you haven't stored yet, it pauses and surfaces a **Credential required** prompt in the chat. Fill it in and Studio saves it to the vault and injects it into the running workspace immediately - the agent's next step picks it up without restart. You can also defer with **Later** if you'd rather not provide the value right now. [Archiving a job](https://docs.frontic.com/studio/frontic-studio.md#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. **studio/preview-panel** Studio Preview panel showing a live-rendered page with refresh, viewport toggle, open-in-new-tab, and download controls ![Studio Preview panel showing a live-rendered page with refresh, viewport toggle, open-in-new-tab, and download controls](https://mintcdn.com/frontic/hS7rYTW0C-o2HHTZ/images/studio/preview-panel-light.png?fit=max\&auto=format\&n=hS7rYTW0C-o2HHTZ\&q=85\&s=baf5be3d3a84749a0b1ff98d7fe41736) ### What you can do in Preview > [card] Refresh > > Force a reload of the preview. Useful when a file change doesn't > trigger a hot-reload automatically. > [card] Switch viewport > > Toggle between desktop and mobile viewport sizes. Commerce > experiences need mobile testing - do it without leaving Studio. > [card] Open in a new tab > > Launch the preview in its own browser tab. Better for long > interactive testing where you want the full viewport, or for > sharing a preview URL with a teammate. > [card] Download the project > > Grab a snapshot of the entire workspace as a zip. Useful for > experimental projects or for moving the work to another environment > entirely. > [card] Upload static assets > > Drop static application assets - logos, icons, fonts, or config > file - straight into the workspace. On upload, the agent is > notified and moves the file to the right directory in the project, > ready to use in the code. > [card] Select elements > > Click elements in the preview to ground your next message in > specific UI nodes. Picked elements appear as numbered chips in the > chat input and are included in the prompt, so the agent knows > exactly which component you mean. ### Selecting elements for context Sometimes the fastest way to point the agent at something is to point at it. **Select elements** mode lets you pick nodes directly in the live preview and attach them to your next message - the agent then knows exactly which component you mean instead of parsing a description. **1. Turn on select mode** A floating **Select elements** control sits at the bottom-center of the preview whenever a preview is loaded. Click it to enter select mode - the cursor becomes a crosshair and a highlight follows your pointer across the page. **2. Pick the elements you mean** Click any element to capture it. It gets a numbered marker in the preview and a matching numbered chip in the chat input. Keep clicking to add more - the overlay shows a running count. **3. Annotate a pick** Optional: click a numbered marker in the preview to open its comment card, then type an instruction for that specific element - "make this green", "remove this". The comment shows under the matching chip in the chat input. One comment per element. **4. Send** Write your message and send as usual. The picked elements - and any comments - are included with the prompt so the agent can locate and act on each exact node. To drop a single pick, click the × on its chip; to clear everything at once, use the × in the overlay counter. Select mode is scoped to the Preview tab - switch to Changes and it turns off automatically. Once you send a message, select mode turns off and the picks and comments clear. ### 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. **studio/changes-panel** Studio Changes panel showing a file tree of modified files, a line-by-line diff view, and the commit message input ![Studio Changes panel showing a file tree of modified files, a line-by-line diff view, and the commit message input](https://mintcdn.com/frontic/hS7rYTW0C-o2HHTZ/images/studio/changes-panel-light.png?fit=max\&auto=format\&n=hS7rYTW0C-o2HHTZ\&q=85\&s=d91494a29e8a5af69f959696810fb131) ### 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 A job started from a framework template has no repository yet, so there is nothing to show. Instead, the panel says no repository is connected and offers **Create Repository** to [create one from the job](https://docs.frontic.com/studio/github-integration.md#create-a-repository-from-a-job). ### 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. **1. Open the Changes panel** Switch from Preview to Changes. **2. Read every file, not only the ones you expected** Agents sometimes touch files you didn't mention - imports, shared utilities, generated files. Read those too. **3. Check for the things that matter** * Did the agent pass `requestUrl` to Frontic API calls? * Did it handle the non-200 cases for `client.page()`? * Did it use the typed SDK methods instead of raw fetch? * Did it reference design system components you have? * Are imports clean, or did it leave orphaned ones behind? **4. Flag issues in chat, not in the diff** If you find something wrong, tell the agent in the chat. "The search input on line 42 isn't debounced - can you add a 300ms debounce?" The agent edits the file, and the Changes panel updates. Don't hand-edit the file - let the agent keep its mental model. ## 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: **1. Describe the task** Tell the agent what you want to build. Be specific enough that the agent doesn't have to guess, vague enough that it has room to propose structure. **2. Review the agent's plan** The agent responds with a plan - which files it'll touch, which backend pieces it needs, any clarifying questions. Confirm or redirect before it starts executing. **3. Watch the preview** As files change, the Preview panel updates with the live result. Click through the actual UI - not only the chat's summary of what it did. Need the agent to focus on something specific? [Select it in the preview](#selecting-elements-for-context) to ground your next instruction. **4. Review the changes** Open the Changes panel to inspect repository status and the full diff. Read the files the agent touched, including the ones you didn't explicitly ask about. **5. Ship it** When you're happy, commit from the Changes panel. If [GitHub](https://docs.frontic.com/studio/github-integration.md) is connected, the branch pushes and you can open a PR from the compare link. If not, the work stays in the workspace - download it or share the preview URL with a teammate. Started from a template and want a repository? Use **Create Repository** in the workspace toolbar to [create one from the job](https://docs.frontic.com/studio/github-integration.md#create-a-repository-from-a-job). ## Tool approvals Studio surfaces an **approval prompt** before each tool call the agent makes - file edits, code searches, shell commands, browser actions. You see the tool, its arguments, and confirm or deny before the agent proceeds. The prompt arrives as a message in the chat. This is separate from [Plan mode](https://docs.frontic.com/studio/frontic-studio.md#plan-mode), which gates the agent's plan up front, and from the Credential required prompt, which asks for a missing secret. By default, every job runs in **Always ask** mode - the agent pauses on each tool call. The chat input toolbar has a shield toggle to switch to **Skip approvals**, which auto-approves every tool call without prompting. Click it again to switch back. The setting is saved per user per project, so a teammate working on the same project keeps their own preference. The toggle sits in the chat input, so only the job's [owner](#who-can-act-in-a-workspace) sees it, and only the owner can answer an approval. When to switch to Skip approvals: * You're iterating fast on trusted, low-stakes work and the per-step prompts are getting in the way * You've already reviewed a Plan and want the agent to execute without interruption * You're rerunning a well-understood task the agent has done before When to keep Always ask on: * Unfamiliar tasks where you want to watch each step * Destructive operations, or anything you'd want to catch before it runs * New skills or rules where the agent's tool choices haven't earned trust yet ## Who can act in a workspace Each job has one [owner](https://docs.frontic.com/studio/frontic-studio.md#job-ownership), and only the owner can drive the agent in its workspace. Anyone else who opens the job gets a view-only chat: * the chat history and the agent's progress, but no chat input - a view-only notice takes its place at the bottom of the chat * no way to answer the agent's questions, plan approvals, tool approvals, or Credential required prompts * the asset upload button in the workspace toolbar disabled A teammate can still watch the preview and read the diff in the Changes panel while the owner works. Opening a job never interrupts the owner, and several people can have it open at once. If the agent is in the middle of a turn, you see the conversation so far first, then follow the agent live. To take over the chat, claim the job. ### Seeing who's there Next to the breadcrumb at the top of the page, avatars show the job's owner first, followed by everyone else who has the job open right now. Hover a viewer's avatar to see their name. The ring around the owner's avatar shows what the agent is doing: solid green while it's working, pulsing green while it winds down, plain when it's idle. The owner's avatar also appears at the right end of the workspace toolbar. ### Claiming or reassigning from the workspace Click the owner's avatar, in either place, to change who owns the job: * **Claim job** makes you the owner, so you can take over the chat. It shows when you aren't the owner. * **Assign to** lists the other members of your team, sorted by name, with a check mark next to the current owner. Pick someone to hand the job to them. These are the same actions as on the job's Board card, and anyone who can create jobs in the project can use them, not only the current owner. ## 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 > [card] [GitHub Integration](https://docs.frontic.com/studio/github-integration.md) > > Commit, push, and open a PR from the Changes panel. > [card] [Context Base](https://docs.frontic.com/context-base/overview.md) > > How Skills, Rules, and Commands shape the Studio chat's behavior. > [card] [Settings](https://docs.frontic.com/studio/settings.md) > > Project-wide defaults that apply across every job. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.