Run agents on your machines with Claude Code or Codex, and register repositories as Works
A machine you enrolled in Fleet can now run a Task's agent itself with a local Claude Code or Codex, across several repositories, and stop to ask you a question in the Inbox. Any GitHub repository you can read can become a Work, and MCP clients gain 57 tools for Tasks, the Inbox, Goals, Fleet and Agents.
This release reached production on 4 September 2026. Most of it lets agents work on your code with the machines and tools you already have.
A machine you enrolled in Fleet can now run a Task's agent itself with a local Claude Code or Codex. The result comes back the way a cloud run does: a pushed branch, a pull request and a report on the Task. Those runs can change several repositories at once, and the agent can pause to ask you a question in your Inbox. You can also pin an agent to one machine from its Capabilities tab.
Outside Fleet, any GitHub repository you can read can be registered as a Work, and MCP clients such as Claude Code can now create and steer Tasks, triage the Inbox, run Goals and start or cancel agent runs.
The fleet features need the node app running on your machine and the model-cli execution mode, which is not the default. Each entry says what it needs.
On this page
Features(5)
- New featureFleet & nodes
Run a Task's agent with your own Claude Code or Codex on your machine
A machine enrolled in Fleet can now do the agent work itself: it runs your local Claude Code or Codex on the Task in an isolated checkout, grades the checks and pushes the branch. Ever Works then opens the pull request.
A fleet machine could only run a fixed command for a Task. In the new model-cli execution mode, Ever Works writes the agent's instructions and your machine runs Claude Code or Codex on them with your own CLI login.
- Isolated work. Each run gets its own Git worktree of the Work's repository. The machine grades the acceptance checks, then commits and pushes the Task branch.
- The same trail as a cloud run. The CLI's final message becomes the run summary, the pushed branch becomes a pull request, the Task moves to In review, the report lands in the Task chat and a failed run files an Inbox notice.
- Cancel reaches the machine. Cancelling the run stops the CLI there.
Turning it on: the account's job runtime has to be Fleet nodes (Settings → Job Runtime) and the Fleet Node Job Runtime's agent execution mode has to be
model-cli, with a CLI, model and run limits chosen — there is no self-serve switch for it yet. Then start the node app withstart --workon a machine that has that CLI; only machines reporting it get the job.Limits:
commandstays the default mode, the node app is still built from the open-source repository, and the CLI's permission prompts are skipped only if you allow it. - New featureWorks & deploys
Register an existing GitHub repository as a Work
A new Repository kind turns a code repository you already have into a Work, so agents, Tasks and Goals can work in it. No website, template or deployment is created for it.
Until now every Work was something Ever Works builds, such as a directory, a website or a blog. A Repository Work wraps a code repository you already have, so agents, Tasks and Goals have something to attach to.
- On the New page (
/new) or on/works/new, pick the Repository chip. - Paste the GitHub URL, for example
https://github.com/owner/repo. The name, slug and description are filled in from it, and you can change them. - Select Register Repository.
The repository becomes the Work's data repository as it is. No website template, provider repository or deployment is created, the Generator and schedule pages are not offered, and the platform's content generators refuse to write into it. The Overview shows agents, open Tasks and days active.
Limits: GitHub only for now. Ever Works checks that your own connected GitHub account can read the repository, so connect GitHub first. A repository can be registered by one account only — a second account is refused. Knowledge Base documents you add to the Work are committed to the repository's default branch under
.content/kb/. - On the New page (
- New featureMCP & developers
Drive Tasks, Inbox, Goals, Fleet and Agents from any MCP client
The Ever Works MCP server gains 57 tools, 123 in all, so an assistant such as Claude Code can create and run Tasks, triage the Inbox, run Goals, check your Fleet and start or cancel agent runs.
The MCP server already covered Works, generation, items, deploys, plugins and schedules. It now reaches the work itself, with 57 new tools:
- Tasks (23): create, update, assign and run Tasks, read a Task's pull request status, diff, chat and spend, and reject a result with feedback.
- Inbox (7): list, read, mark, archive and delete items.
- Goals (10): create, activate, pause and evaluate Goals, change their limits, and propose done criteria for a person to approve.
- Fleet (8): list your machines, check whether a runner is free, pin an agent to a machine and drain a machine.
- Agents (9): list agents and their runs, start or cancel a run, pause or resume an agent, and read its budget.
Decisions stay with people. The tools can ask but not answer. Replying to an Inbox item, resolving an escalation, approving done criteria and forcing a Task past its approvers are left out on purpose, so an agent using the server cannot approve its own work.
Limits: tools run in your personal scope unless the server is started with an Organization slug (
EVER_WORKS_SCOPE_SLUG). Pinning an agent to a machine needs one. - New featureTasks & goals
One Task can change several repositories, with a pull request for each
When a Task runs on one of your machines, the repositories attached to its agent, or picked under Also work in, are checked out next to the main one. Each repository that changes gets its own pull request.
Real changes often cross repositories: an API field in one, the screen that uses it in another. A Task still has one main Work and branch, and it can now bring more repositories along.
- Choose them. Attach repositories to the agent under Capabilities → Repositories, or tick them under Also work in on the new Task form or the Task page. Both lists come from Settings → Repositories. A Task's choice wins over the agent's for the same repository.
- The run sees them. The machine checks each one out at
.mounts/<name>inside the main checkout, on the same Task branch name, and tells the model where each one is. - Review them. Every repository that changed is pushed and gets its own pull request, linked to the main one. The Task's branch panel lists them under Also in, and one Inbox notice links every pull request.
Limits: this applies to runs on your own machines in
model-climode, not to cloud runs. A Task can bring at most 8 extra repositories, and acceptance checks run in the main repository only. A repository with no GitHub connection behind it is pushed but gets no pull request. If Ever Works cannot read a repository's details, the run fails naming it instead of running without it. - New featureInbox & decisions
An agent on your machine can pause and ask you a question in the Inbox
When a run on one of your machines reaches a decision only you can make, the agent stops with a question. Answer it in your Inbox and a new run continues the Task with your reply.
An agent running on your own machine cannot message you mid-run. It can now park the run with a question instead of guessing.
- The question reaches your Inbox, tagged From your fleet, with the machine, the Task, the branch and a link to any pull request. The Task page shows that the run is waiting and links to the question.
- Partial work is kept. What the agent did so far is pushed on the Task branch when its git policy allows it, but no pull request is opened and the Task does not move to In review.
- Replying starts a new run for the same Task, with the same agent, pinned machine and branch. Your question and answer are part of its instructions.
- Archiving the question stops the parked run from waiting.
Limits: this is for runs in
model-climode on your own machines. One question per run, answered in free text with no option buttons. An agent in theplanpermission mode cannot ask. A reply to a Task that is already Done or Cancelled does not start a run.
Improvements(1)
- ImprovementFleet & nodes
Pin an agent to one of your machines from its Capabilities tab
Choose a Preferred node for an Organization agent in the app instead of through the API, and see the routing rule in force. Each machine's details in Settings → Fleet now show its full job history.
Pinning an agent to a machine used to need the API. Now open the agent, go to Capabilities → Execution and choose a Preferred node.
- Pinned work waits for its machine. With a node chosen, only that machine takes the agent's jobs. If it is offline or drained, the jobs wait instead of failing, and the picker tells you so.
- Any node, the default, lets whichever of your machines is free take the work.
- Removed machines stay visible. If the pinned machine was removed from your fleet, the picker still shows the pin so you can clear it or choose another machine.
- Routing at a glance. The section shows your account's execution routing rule, read-only, with a link to change it in Settings → Fleet.
Job history per machine. On Settings → Fleet, a machine's details now list every job, not only failures: kind, status, attempts, queued, started and finished times, duration and why a job is still waiting. Filter by All, Failed or Running.
Limits: pinning is for Organization agents; in a personal workspace the section explains this instead. A new pin applies to future jobs only.
Plus 11 fixes in the GitHub release notes (opens in a new tab).