The Studio

The Studio is where you write, run and watch automations. It runs in a browser on your machine. It edits the same TypeScript files the Robot executes. There is no project file, no database of steps and no second copy of the work. Open the Studio and you are looking at the repository.

That is the design rather than a shortcut. The header says it plainly: TypeScript is the automation, the Studio is a view. The workflow diagram is derived from the code each time you open a file, so the picture and the source cannot drift apart. The Studio server never runs an automation in its own process either. When you press Run it spawns the Robot the same way a scheduler would, then follows the run folder the Robot writes.

#Starting the Studio

Two commands cover most of the work. For development:

npm run studio

That starts the API server on 127.0.0.1:4174 and a Vite dev server on 127.0.0.1:4173. The page opens on the second port. Vite proxies /api to the API server, so both halves behave as one origin while you work.

For a single process serving the built page and the API together:

npm start

That runs npm run build:studio first, then starts the API server on :4174 and serves the built UI out of studio/dist. The other scripts are narrower: npm run studio:server starts only the API, npm run studio:web starts only Vite and npm run build:studio only builds. The API server is plain Node with no web framework. It reads TS_STUDIO_HOST and TS_STUDIO_PORT if you need to move it off the loopback default.

#What the tabs do

The header carries seven tabs. Each one is a view of something that already exists on disk.

• Explore is the file tree and the code editor. It is the tab you will live in.
• Generate (AI) drives the generator that turns a described process into an automation.
• Orchestrator reads the local control plane: queues, robots and schedules.
• Authoring scaffolds and validates an automation through the same CLI you would run by hand.
• Target Health aggregates the target resolutions from past runs.
• Debugger opens one finished run and explains its outcome from the run's own evidence.
• Desktop Recordings is the browser side of desktop work: recordings, a live hierarchy and the prover.

None of these holds state of its own. Each reads a file, a run folder or the output of a command, then shows it.

#Why it is built this way

Two consequences follow from "the code is the artifact". The first is review: a change you make in the Studio is a change to a .ts file, so it appears in a diff and goes through a pull request like any other code. The second is exit: the automation keeps running under the Robot even if you never open the Studio again, because nothing the Studio owns is load-bearing.

The Studio is also where the two writing aids live. The diagram beside the editor is read back out of the automation, and clicking a node jumps to its source line. Nothing has to be kept in step by hand, because there is only one thing to keep in step and it is the file.

#Things that catch people out

• In development the page is on :4173 and the API is on :4174. Bookmark the Vite port while you work.
• npm start serves everything from :4174, but only after a build. Change the source and you build again.
• A Studio server older than the page it serves does not know newer routes. A page that calls one reports a plain unknown api error. Restart the server after pulling new code.