What's new in Goatfied.

Aug 14, 2026

One list for every session

Work running on our machines now sits beside the work running on yours, in the same list, marked with a cloud.

Where a piece of work happens is a detail about it, not a reason to keep it somewhere else. Until now a run on our machines lived behind its own heading, with its own list, its own filters and its own idea of what counted as recent — so knowing what was in flight meant looking in two places and holding both in your head.

It is one list now. A run on our machines appears in your sessions alongside everything else, filed under the same project, sorted by the same recency, and carrying a small cloud so you can tell at a glance where it is happening. Naming one, pinning it, ticking it off and filing it away all work exactly as they do for anything else. Opening one shows the run itself — its steps, its cost, the branch it is on and the pull request it opened.

The filters follow. You can narrow the list to work happening on your machine or on ours, group by it if that is how you think, and widen the view to the whole team when you want to see what everybody has in flight rather than just yourself.

Starting a run no longer requires going anywhere. Hand an open session off and the task comes with it, already written; or start one against any repository from the same menu you use to open a folder. What used to be the cloud section is now what it always actually was — the place you prepare machines, grant repository access and set spending limits.

Build 2.27.0

Aug 13, 2026

Cloud runs grow up

Prepare a machine once and reuse it, let a run start on a schedule or a comment, and watch the whole team's work in one place.

Setting a cloud run up used to happen at the start of every single run: install the dependencies, wait, and only then begin the work you actually asked for. You can now prepare a machine once, ahead of time. The preparation happens in the background while you carry on, and every run after it starts from a machine that is already ready. If your project already describes its own machine, that description is used as-is rather than approximated.

Before you spend a run finding out a setup step was wrong, you can check it. A quick review reads the definition, tries to reach the repositories, and tells you what would fail and why. If you would rather not write the definition at all, describe the project and one is drafted for you from what is actually in the repository.

Runs no longer have to be started by hand. A run can fire on a schedule, whether or not anyone is at a machine, or when someone mentions the agent on an issue or a pull request. When a check fails on a branch a run opened, it can pick the failure up and try to fix it — off by default, and it stops the moment you tell it to.

The tools you have connected come with the run. Whatever a run needs to reach outside the repository is available inside the machine, and any checks you have set up for your own work apply there too. Recordings, screenshots and summaries can be attached to the pull request itself, so the review starts with the evidence.

Your team can finally see each other's work. Runs default to your own and switch to the whole workspace in one click, each one says whose it is, and steering somebody else's run stays off until an admin decides otherwise. Cloud spending has its own ceiling, separate from everything else.

Connecting repositories no longer means handing over a personal token that reaches everything you can reach. Grant access to the repositories you choose, revoke it whenever you like, and each run receives credentials scoped to exactly that grant and nothing more.

A run's progress now arrives as it happens rather than in batches, and a run can be limited to a list of domains it is allowed to reach.

Build 2.26.0

Aug 12, 2026

Cloud agents read, run and show their work

A run now explores your project the way you would, checks what it changed, and records a walkthrough you can watch.

A cloud agent used to get one guess at your project and one chance to act on it. It never opened a file and never saw what its own commands printed. A run now works its way through a project the way a person does: it looks around, reads the files it needs, searches for what it cannot find, makes a targeted edit, and runs whatever it takes to check the result — reading the output each time before deciding what to do next. It keeps going for as long as the task takes rather than stopping after a fixed handful of moves.

Because it can now check its own work, it also knows when there is nothing to show. A run that ends up changing nothing says so instead of opening an empty pull request, and the pull request it does open explains what it set out to do and what it actually did, rather than repeating the commit message back at you.

Runs against an environment that serves a preview now record a walkthrough. The recording plays in the run itself and is linked from the pull request, so you can watch the change work before you read a line of it. Screenshots come with it.

The model you pick is the model that runs. Whichever one you choose is carried into the cloud with the work instead of being quietly swapped for a default, and every model in the picker is available there.

Choosing where a run happens has moved to where you decide it. The picker sits beside the model picker in the prompt itself — when you start something new, when you follow up, and when you kick off a run from the editor — so switching between your machine and ours is one click at the moment it matters.

Build 2.25.0

Aug 12, 2026

Cloud agents get a machine that can actually do the work

Tell a cloud agent which repositories to check out, how to install them, and how to test them — and watch each step as it happens.

A cloud agent used to get a bare machine with a single public repository and nothing installed. There was no way to give it a credential, so a private repository was out of reach, and no way to install dependencies, so anything whose tests needed them could not be checked. An environment now describes the machine once: the repositories to check out, the commands that set them up, how to test and start them, and how large the machine should be. Point a run at it and every agent on your team gets the same setup.

Credentials belong to an environment and are stored encrypted; once saved, nobody can read one back, including us. Give each environment only what its work needs — the agent working on your documentation has no reason to hold a payments key. A credential marked build only is available while dependencies install and is gone before the agent starts, so an install token never ends up somewhere it can be used.

Every change to an environment is kept. You can see what it looked like before and put it back in one click, and a run that has already finished keeps the setup it ran with, so editing an environment can never quietly change the story of work that is already done.

Watching a run is no longer a matter of waiting for a status to change. Runs sit in a list showing the step each one is on, and opening one shows its plan, everything it has tried, what its tests said, and the screenshots it took, as it happens. You can send a follow-up without leaving the run, take the branch straight into your open project, or stop it.

One quieter fix worth knowing about: a run with no test command used to report that its tests had passed and open a pull request on that basis. It now says plainly that the change is unverified. Runs also show what they cost, and there is a limit on how many can run at once so an automated trigger cannot spend without bound.

Build 2.24.0

Aug 11, 2026

Settings opens, and an edit that changes nothing says so

Settings in the File menu did nothing at all when clicked, and an edit that left a file exactly as it found it was still reported as an edit.

Choosing Settings from the File menu, or pressing its shortcut, was silent — the menu closed and nothing opened. It opens now, over the editor or over your sessions, whichever you are in. Every other item in that menu was checked the same way, and there is now a test that fails the build if a menu item is ever added without something behind it.

The Help menu on Mac was empty. It now carries the documentation, this changelog, and a link for reporting a problem.

Separately: an edit whose replacement text was identical to the text it replaced wrote nothing, yet came back as a completed edit. The agent had no way to tell, so it would move on believing a change was in place that was not. That case is now reported as the failure it is, which is enough for the agent to notice and fix it rather than build on it.

Build 2.23.0