Preview agent: permissions, commands, and auto-PR

The coding agent in the live preview gets clear guardrails: per project, you decide which tools it may use, what it's allowed to do in the preview containers, and which commands run before and after each run. And every successful run now ends in a pull request automatically — so nothing the agent builds sits around without your review.

Permissions: you decide what the agent may do

Under Project → Settings → Agent Setup there's a new Preview Agent section. This is where you control what the agent may do during a run in the preview:

• Restrict tools — By default, the agent may read and edit files. If you want it tighter, enable the restriction and pick the allowed set individually: read, edit, search, web research, and more. A shell is never on the list — the preview agent fundamentally gets no Bash.
• Preview & container access — Three toggles define how the agent may verify its own changes: fetch the live preview over HTTP (preview_fetch), run commands in the preview containers (preview_exec), and read container logs (preview_logs). All three are on by default, run through a hardened per-run gateway, and every call is logged — with no shell access and no Git credentials.

That's the division of labor we believe in: the agent can check on its own whether a change actually works — but only inside the boundaries you've drawn.

Pre- and post-run commands

Some projects need a bit of housekeeping around an agent run: install dependencies before the agent starts, or recompile a theme so the change actually shows up in the preview. That's exactly what the new pre-run and post-run commands are for — configurable per project, right in the same section:

• Pre-run commands run before the agent, e.g. npm ci. If one fails, the run aborts before the agent starts — it never works on a half-built environment.
• Post-run commands run after the agent, e.g. bin/console theme:compile && bin/console cache:clear on Shopware. A failure here only produces a warning; the run still succeeds.

Each command can optionally target a specific compose service — without one, it runs in the primary container. Individual commands can be toggled off without deleting them.

This is deliberately the controlled alternative to an agent shell: instead of letting the agent run arbitrary commands, you define once what your project needs — and exactly that runs on every run, reliably and traceably.

Auto-PR: every run ends in a pull request

Until now, you had to click Create PR in the ticket yourself after an agent run. That changes: after every successful run, Spedy commits and pushes the changes and automatically opens a pull request. If one already exists for the branch, it's reused and linked in the ticket.

The idea behind it: the pull request is your checkpoint. The agent proposes — nothing merges until you've reviewed. With auto-PR, every proposal lands immediately where your review process already happens, instead of quietly waiting on a branch.

This is a behavior change with the default set to on. If you prefer creating PRs manually, disable the Create pull request automatically toggle in the preview agent's permissions — the manual button then stays in place.

Also new: if the project has a runner team assigned, its system prompt including assigned skills now applies to preview runs too — so the agent behaves in the preview exactly the way you've configured it for runner jobs.

Cleaned up: preview-stack selector removed

Board settings used to have a Preview Stack dropdown. It's gone — without replacement, and that's good news: previews always boot your own repo's stack, i.e. your docker-compose.preview.yml plus .spedy/preview.yml, as described in the preview configuration. The selector no longer had any effect and could only cause confusion. There's nothing you need to do.

One consistent design across the dashboard

Finally, something for the eyes: the entire web frontend has been migrated to our design system. Buttons, inputs, badges, and status indicators now look the same everywhere — status is consistently shown via a subtle colored dot instead of colored panels, surfaces are calmer, and dark mode is consistent across all areas. Functionality doesn't change; the interface simply feels tidier and more uniform — from time-tracking reports to wiki settings.

All changes are available now. Questions or feedback? Reach out via the contact form.