What's new in Goatfied.

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

Aug 11, 2026

A step that failed now says so

When a tool failed, the agent was handed the failure in exactly the place a result normally goes — so it sometimes read the failure as the answer and reported work that never happened.

A tool that succeeds returns text. A tool that fails also returned text, in the same field, with nothing to tell the two apart. Only failed file writes were called out; everything else — a query that errored, a fetch that timed out, a command that exited non-zero — arrived looking like an ordinary answer. Every failure is now labelled as one, on its first line, whether it ran on its own or alongside seven others.

Some commands were also being let go too early. A command was read as a server if the letters of a server's name appeared anywhere in it, so an ordinary script whose name merely contained them was started, watched for three seconds and reported as running — long before it had done what it was asked to do. Those signatures now have to match whole words.

A command that had to be stopped could also leave its card spinning for hours afterwards if anything it had started still held the output open. It now closes when the command does.

The status line at the foot of a running session used to repeat the whole command already shown above it, wrapped across several lines. It says what is happening and leaves the detail to the card. The nudge asking whether a long-running agent was stuck is gone too; it fired on the clock rather than on evidence, and the notice that does check is still there.

Build 2.22.0

Aug 11, 2026

One dot per session, and it means something

Every session row carried two coloured dots and neither had a key. There is now one, and it answers a single question: what is this agent doing right now?

Green means the agent is sitting still. Blue and pulsing means it is working. Red means it stopped on an error. Amber is new and is the one worth watching for: the agent has asked you something — a question, a confirmation, a permission — and will not move until you answer. Sessions in that state also collect under Needs Attention, which until now only meant failures.

The second dot used to mark output you had not read. That is now carried by the session's name instead, which is where the unread text actually is, and leaves the leading edge to say one thing.

The mark showing how far a session's work has got also reaches more sessions. It used to measure the folder you opened, which is often a folder of repositories rather than a repository — in which case there was nothing to report. It now follows the files the session actually edited to the checkout they belong to.

Build 2.21.0