Guided setup is how SuperDevSpace closes that gap. The agent opens the site in the app's own browser, does the clicking it is allowed to do, and hands the page to you, with a pointer and a sentence, exactly when the next step is yours.

Why "just let the agent do it" is the wrong answer

The easy version of this feature would give the agent the whole browser: read every field, type into every box, press every button. That would be fast, and it would be a bad idea. A setup flow is full of things an agent should never touch:

• your password and the one-time code from your phone;
• card numbers, bank details and identity documents;
• the terms you agree to and the payment you approve.

So the design starts from the opposite end. The agent does the routine work — navigate, find the right page, fill in a project name, press Create — and everything personal or binding stays with you.

How a guided setup runs

The loop is the same on every site, including ones nobody has written instructions for.

When it is done, you can check the result without printing a secret to your screen:

$ grep -o '^PADDLE_[A-Z_]*=' .env
PADDLE_API_KEY=
PADDLE_CLIENT_TOKEN=
PADDLE_WEBHOOK_SECRET=
PADDLE_ENVIRONMENT=

Rules the app enforces

These are checks in the app, and the agent cannot switch them off:

• No secrets in, no secrets out. The agent cannot type into a password, card, CVC, IBAN, one-time-code or ID field. When it reads the page or takes a snapshot, those values are hidden, and they are scrubbed from any text it reads.
• Screenshots are painted over. Sensitive fields and every cross-origin frame — a card widget, a "Sign in with Google" box — are covered before an agent sees an image.
• No scripts on sensitive pages. Running JavaScript in the page is refused on any page that shows such a field.
• Consent and payment are yours. Clicking a terms checkbox or a "Pay" / "Place order" button is refused.
• Everything is visible. What the agent does in the browser pane is shown to you in the pane's banner as it happens.
• Secrets stay out of the conversation. A value read as a secret is marked sensitive, and the agent is told never to repeat it in chat, reports, task notes or notifications.

Any website, not a list of integrations

Guided setup is a loop, not a library of scripts. It works on a site nobody has written a hint for, because the agent reads the actual page in front of it. For a few services we ship short hint files — Paddle's sandbox dashboard and RevenueCat, for example — that tell the agent where the developer settings usually are. Dashboards move their menus all the time, so the hints say plainly: when the page and the hint disagree, trust the page.

That matters more than it sounds. The integration code an agent writes is only half of a feature; the other half is the account, the key and the webhook on someone else's website. With guided setup, both halves happen in the same session, with the same agent, and you spend your time on the steps only you can do.

Where it fits

Guided setup is part of the same workspace as everything else in SuperDevSpace: the agent that writes your checkout integration is the one that walks you through creating the keys for it, in a browser pane next to its terminal. If you are new here, why we built SuperDevSpace explains the rest of the team around it.

Try it

The trial is 14 days of Premium, no card. Download SuperDevSpace, ask an agent to set up a payment or analytics provider for your project, and let it hand you the page when it is your turn.

SuperDevSpace runs a manager and several workers on one repository at the same time. This post explains the mechanism that keeps them apart — git worktrees — and the exact rules the app follows around them.

What a git worktree is

A git repository normally has one working directory. git worktree lets a single repository have several, each checked out on its own branch, all sharing the same object database. There is no second clone and no second copy of the history: a new worktree costs the files of one checkout and nothing more.

You can try it by hand in any repository. The commands are the same everywhere; only the shell differs:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Each worktree has its own HEAD, its own index and its own files. Two processes can edit, build and test in two worktrees at once without seeing each other's half-finished changes. That is exactly the property a team of agents needs.

How SuperDevSpace uses them

The rules are simple, and they are the same for every organisation:

• The manager works in your main checkout. It plans, reviews and merges; it is the one place where branches come together.
• Every worker gets its own worktree on its own branch. When the manager hires a worker, the app runs git worktree add -b <branch> <path> for it. The branch is named agent/<worker-name>-<stamp> unless you gave it a name yourself.
• Worktrees live in the app's own data folder, under worktrees/<organisation>/<worker>, never inside your repository. Your project folder does not fill up with agent directories.
• Every turn is committed. When a worker finishes a turn, the app commits whatever changed in its worktree (agent(<name>): turn). Nothing a worker did is ever only in an uncommitted working directory.
• Merging is a squash merge. When the manager accepts a worker's report, the branch is merged into your line with git merge --squash and one commit. If the merge conflicts, the app aborts it and leaves the repository clean for the next operation instead of leaving you in the middle of a conflicted merge.
• One git operation at a time per repository. The worktree directories isolate the files; a per-repository queue serialises the git commands themselves, so two workers finishing at the same moment never race on git's metadata.

On the board this looks like several tasks in progress at once, each owned by a different worker, each with its own branch underneath.

The parts that make it practical

A fresh worktree contains only what git tracks. That is usually not enough to run a project: node_modules, a local .env, generated files. Two details handle this.

A setup script per repository

If your repository has .super/scripts/setup-worktree.sh, the app runs it inside every new worktree before the worker starts, with SUPERDEV_MAIN_REPO pointing at your main checkout. Its output streams live, so a long install is not a blind wait, and you can cancel it.

#!/usr/bin/env bash
set -euo pipefail
# Copy local-only files from the main checkout
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Install dependencies (pnpm links from one shared store, so this is quick)
pnpm install --frozen-lockfile

Submodules

git worktree add leaves submodules empty. If the new worktree has a .gitmodules file, the app runs git submodule update --init --recursive in it, so a worker never builds against a quietly missing dependency.

Cleaning up without losing work

Worktrees accumulate. The app reclaims them, but it is conservative about it:

A worktree with uncommitted changes, or with a branch that has work not yet in your line, stays where it is. A deleted folder can be recreated; lost work cannot. The same caution applies to branches: the app keeps track of the branches it created, and it only touches those.

What this changes for you

With each worker on its own branch, "run four agents at once" stops being a gamble. You can:

• give the manager a directive that splits into independent tasks and let the workers run in parallel;
• read any worker's diff on its own, next to the conversation that produced it;
• reject one worker's change without disturbing the others;
• keep using your main checkout yourself while the team works.

It is the same discipline a human team uses, applied to agents that cannot tell you they are about to step on each other. If you are wondering why we built a whole app around this, the first post tells that story.

Try it

The 14-day trial is Premium, with no card. Download SuperDevSpace, point a new organisation at a repository, and watch the worktrees appear as the manager hires its first workers.

That gap is why we built SuperDevSpace. It is a desktop app that turns the CLI you already have into a small team: a manager that plans the work and workers that do it, each in its own terminal and its own git worktree.

The problem with one agent in one terminal

Working with a single coding agent feels great for a single task. It falls apart the moment you have three things to do in the same repository:

• You can open a second terminal, but both agents now edit the same checkout. One of them runs the test suite while the other is halfway through a refactor.
• You become the project manager. You split the work, you remember which terminal had which task, you copy context from one session to the next.
• Nothing writes down what happened. When you come back after lunch, the only record is a scrollback buffer.

None of this is a model problem. It is an organisation problem, and organisation is something software is good at.

What SuperDevSpace actually does

In SuperDevSpace every repository is an organisation. Each organisation has a manager: a real agent CLI session running in a real terminal that you can see and type into. You give the manager a directive in plain language — by typing, or by dictating it with voice typing.

The manager then does what a lead would do:

You can always drop in. Every agent has a chat view and its real terminal — one session, two ways to look at it — and every change shows up as a diff next to the conversation that produced it, so you review before it lands on your main line.

Your subscription, your machine, your code

The most important design decision is also the simplest: SuperDevSpace drives a CLI you already pay for. We never resell model access, so nothing you run shows up on a bill from us beyond the SuperDevSpace subscription itself.

That decision has consequences we like:

• Agents run as local processes on your machine, against your local repositories. Your source, prompts, terminal output and file paths are never sent to our servers. Our account service stores an account, a subscription state and a device list.
• You choose the CLI per organisation. Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI and OpenCode are all selectable. Claude Code is the one the app speaks fluently today — hooks, resume, MCP tools, permission answers. The other six start and run; the app marks them experimental and tells you which extras are not wired yet instead of failing quietly.
• Nothing is locked into our cloud, because there is no cloud doing the work.

Before the first directive, it is worth checking that the CLI and the repository are where you expect them:

$ claude --version
$ cd ~/code/your-project
$ git status

The parts around the team

A team needs more than terminals. A few of the things that come with every plan:

• A board that tells the truth. Sprints, tasks, briefs and reports. A report says what failed, not just what passed.
• Inspector. Click an element in your running web page and send it to an agent with the component, file and line attached. It works with Vite, Next.js and static sites.
• Approvals from your phone. When an agent needs a decision, it asks you. The phone app shows the board, the agents and the pending approvals, so you can answer a permission prompt away from your desk.
• A whiteboard per organisation (Excalidraw) that agents can read and draw on.

Premium adds the pieces that reach further: a design mode built on Penpot with a Designer agent that draws in the file, schedules that run directives on a timetable, and a peer link that lets a manager on your Mac hand work to a manager on your Windows PC. The pricing page has the full comparison.

What we do not promise

A team of agents still needs a boss: you decide what gets built, and you approve what reaches your main branch.

Try it

The trial is 14 days of Premium, with no card. Your CLI subscription stays yours, and so does your code. If you want to see the team at work on your own repository, download SuperDevSpace and give the manager its first directive.