What's new in Goatfied.

Aug 13, 2026

A run that ends tells you why

A run on our machines that cannot start now says what stopped it instead of counting, and the recording it made plays where the work is rather than behind a link.

A run that could not begin — no access to the repository, nothing to check out — used to write a line about it and then quietly go away. Going away is not the same as finishing, so the run stayed marked as working and kept counting; one of ours reached eleven hours before anyone looked. Every way a run can end early now ends it properly, with the reason in the place you were already watching.

Only one thing used to be allowed to declare a run over, and a sweep that tidies up after runs nobody spoke for could add a second, different ending on top of the first. Two endings that disagree read worse than one that is merely bad news. A run that has already explained itself is now left alone.

When an agent drives the thing it changed, it records what it did. That recording used to be a link you had to think to click. It now plays in the conversation, next to the screenshots it took, because a diff shows the code changed and only the recording shows that it works.

Build 2.30.0

Aug 12, 2026

Runs that stop when you say stop

Stop now works whatever state a run is in, runs that end without reporting no longer sit there for hours, and a run on our machines reads exactly like one on yours.

Stop did not always stop. If a run had not started yet, or had already ended somewhere you could not see, the request was refused and nothing happened — no change, no message, nothing to act on. The states you most want to escape were the ones you could not. Stop now works from any of them, and when it cannot do what you asked it says so instead of going quiet.

A run that ended without reporting used to stay marked as running for as long as you left it, growing a duration that meant nothing. Nothing was watching for that, so nothing ever resolved it. Something is watching now, and a run that has stopped is marked stopped with a line saying what happened to it.

A run on our machines was shown in a layout of its own, for no reason other than that it had been built separately. It now uses the same view as everything else: the same header, the same goal at the top, the same rows for files read and commands run, the same box to reply in. Where it ran is a note at the bottom rather than the shape of the page.

Build 2.29.0

Aug 11, 2026

The editor catches up

The prompt field beside your code now has everything the agents window has, the sessions list sits next to it, and setting up cloud runs no longer sends you to a browser.

The prompt field in the editor had quietly fallen behind the one in the agents window. It has caught up. Typing a slash offers the commands, typing an at sign offers files, folders and the rest of your context, the up arrow walks back through what you have asked before in this project, and there is a microphone if you would rather say it than type it. The history is the same history — same person, same code, same list, whichever window you happen to be in.

Beside it, the sessions list has arrived in the editor. It is the list you already know, in the sidebar, so you can move between pieces of work without leaving the file you are reading. Renaming, pinning, ticking off and filing away all behave as they do elsewhere, and work running on our machines shows up in it too.

Setting up cloud runs has moved into Settings, where the rest of the setup lives. Preparing a machine, choosing which repositories a run may reach and capping what it can spend are all in one place now, and none of them open a browser — configuring the app no longer means leaving it.

Opening a run that had been recorded in an older format could take the window down with it. It no longer can, and a run that fails to render now says so in place rather than replacing everything around it.

Build 2.28.0

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