What shipped

Deployment-wide instance-operator access, covering cross-tenant cost reporting, rate-card writes, and server metrics, is granted to any account whose email matches an operator allowlist. Because an account holder can freely change their own email, an allowlist match by address alone was not proof that its holder controlled that address: a new signup could repoint their email to an allowlisted one and reach the operator plane without ever confirming it.

Matching the allowlist now also requires that the address itself be verified. This lines up instance-operator access with the same verified-email requirement already enforced for the admin email allowlist and for accepting a workspace invitation.

A related identity fix landed alongside it: revoking or restoring a member’s external identity provider account now addresses it by its own stable identifier instead of by email, so changing an account’s email no longer leaves a stale identity behind, unrevoked, after that member is deprovisioned.

The ch command line tool now works the same way for every kind of item it manages.

Before this change, editing a repository, a device, or a team each used a slightly different command. Now ch <entity> edit changes any entity’s own fields, ch <entity> show reads one entity, and ch <entity> delete removes it. ch device rename and ch member set-role still work; they now just point at edit underneath.

The same rule covers a task’s sub-resources too. Comments, blockers, and agent questions all read as ch task <sub-resource> <action>, with the task id inferred from your current session when you don’t pass one. Learn the shape once and it carries over to the next entity you touch, instead of a new command to look up each time.

The Tasks page has a new Graph view, next to the existing board and list views.

It draws every task as a box and every declared dependency as an arrow between boxes, laid out automatically so related work clusters together. Open it when a backlog has grown past the point where a flat list can show what’s actually blocking what, and you want to see the shape of the work instead of reading it one row at a time.

A workspace on an Enterprise plan can now connect its own identity provider instead of relying on a CodeHerder password.

Sign-in works through SAML, or through Google or Microsoft Entra. CodeHerder checks the sign-in email’s domain against a list your admin verifies first, so one company cannot sign in as another company’s users by mistake. The login screen and the ch CLI’s own login flow both pick up the connection automatically and offer it as a sign-in option.

User accounts can also be created and removed without a person doing it by hand, through the SCIM 2.0 standard. When someone joins your identity provider, a matching CodeHerder account appears. When they leave, their access is revoked and the change lands in the audit trail. For security teams, this closes a gap many of them will not approve a new tool without: sign-in through infrastructure they already control, and account lifecycle they do not have to run manually.

Two agents editing the same file at the same time used to surface as a merge conflict, after the fact. CodeHerder now tracks the files each running task has changed and compares them across the workspace as work happens.

When two tasks overlap, CodeHerder sends a message pointing each one at the other, so a human or an agent can coordinate before either side opens a pull request. An agent starting a new task is also told, in its own brief, which sibling tasks share its part of the codebase right now. The message is throttled per pair of tasks, so an overlap that persists doesn’t repeat the same notice over and over.

CodeHerder has always let agents and teammates leave notes for each other. That store is now a proper wiki: one page can link to another, and the app shows you which pages link back.

Open a page’s history and you get every past revision, a diff against the version before it, and a one-click revert. A built-in check runs over the whole wiki and flags a page with broken front matter, a link to a page that doesn’t exist, or a page nothing links to at all, so the collection can’t quietly rot into a pile of orphaned notes.

Every agent working in a task also gets a writable copy of the whole tree on disk, synced both ways with no extra command: edit a file, and the change reaches the wiki; a teammate’s edit reaches the agent’s folder while it works.

The CLI command is now ch wiki, matching the word people actually use for this. ch memory still works too, so a script that already calls it keeps working unchanged.

Your CI system, your issue tracker, or any tool that can send a webhook can now open a task in CodeHerder directly.

Create an inbound endpoint from the app or with ch inbound-endpoint, then add rules that decide what an incoming event should do: open a task, comment on one, or drop the event. Every endpoint gets a secret for signature checking, and every rule runs against a bounded, declared vocabulary rather than free-form matching, so a typo in a rule fails at setup instead of silently dropping events later. A dry run shows exactly what a sample payload would do before you turn a rule on, and every delivery, matched or not, is kept and browsable from the same page.

CodeHerder now runs a remote MCP server. Point Claude Desktop, Cursor, or any other MCP client at it and your workspace’s tasks, activity, and knowledge pages become tools that client can call directly.

The server signs a client in through OAuth, with discovery documents and dynamic client registration, so there is no shared token to copy around. Once connected, a client can list tasks, read a task’s comments and activity, search workspace knowledge, and read a support doc. It can also file a new task or post a comment on an existing one, with the same authorization rules the web app and the ch CLI already enforce.

This is a second front door onto the same workspace, next to the app and the CLI, not a separate copy of your data with its own rules.

A task type can now require its change to stay small and focused before it moves to the next stage.

Turn the gate on for a task type, and CodeHerder checks the size of the diff and whether it touches unrelated parts of the codebase before letting the task advance. It’s off by default, so it only applies where a team turns it on, and it catches the same problem a human reviewer would flag anyway: a change too large to review properly, or one that bundles two unrelated fixes into a single pull request.

A task’s workflow stage decides what you’re allowed to do with it: approve it, send it back, merge it, delete it. The web app used to work this out itself, client-side, from a few flags on the task, and it could get the answer wrong for an edge case the browser code hadn’t been taught about.

That logic now lives on the server, in one place, and the same place the server itself checks before it accepts your click. A task’s response carries its own list of allowed next stages and allowed actions, and a sandbox or a live session carries the same for its own actions. The app and the ch CLI just render what the server already decided, so what a button offers and what the server will accept can no longer drift apart. If you can’t do something, the reason is the same reason the server would give you if you tried anyway.

The attachment size column on a task used to cut off larger numbers, showing an incomplete figure instead of the real file size. It now always shows the full number, correctly formatted.

Attachments also get a new Preview button next to Download. For an image, a video, an audio clip, or a PDF, it opens the file right where you were, so you can check it and get back to the task without losing your place. Other file types still download as before.

A skill is a written set of instructions an agent follows for a recurring kind of task, like a repo’s own review checklist or a deploy runbook. Until now, adding one meant a teammate outside the app writing the file by hand.

Open a skill now and you get its own editor page: that skill’s files on the left, the selected file in an editor on the right, no separate tool required. A workspace can write a brand-new skill, edit one it already has, or delete one it no longer needs. Every skill can be turned on or off per workspace, and reset back to its original text if an edit goes wrong. The same actions are available from the command line through ch skill.

A flaky connection used to leave you unsure whether a request that timed out actually went through. Retrying it by hand risked leaving a second comment, message, or blocker on a task if the first attempt had landed before the connection dropped.

Those requests now carry an idempotency key generated on the client. If a retry arrives for a request the server already processed, it returns the original result instead of creating a duplicate, and the app and ch only auto-retry a dropped request on the routes where that key makes the retry safe. Everything else is left for you to decide about, rather than being silently re-sent.

Every guide that ships inside the CodeHerder app is now also a public page at codeherder.com/docs, readable without signing in.

It’s the same set of guides the in-app help centre shows your team, published from the same source so the two copies can’t drift apart. Anyone deciding whether CodeHerder fits their workflow can read exactly how it works before they ever create a workspace.

Launching a device on AWS used to ask you to generate a registration token yourself and paste it into the launch form. Depending on how you created it, that token could be good for more than just the one device you meant it for.

The one-click launch now mints its own registration token automatically, so there’s nothing for you to generate or paste. The token it mints acts only as you, it can register a device and mint that device’s own credential and nothing else, it’s refused outright for any device that already has a credential, and it expires within the hour. What used to be a long-lived token you managed by hand is now a short-lived one you never see.

The result is a launch flow that’s both simpler to click through and narrower in what a leaked token could do.

An account that has grown into several workspaces used to have its plan, usage, and spend caps tracked separately for each one, which made a whole account’s real usage hard to see in one place.

Settings now has one account-level page for plan, usage, and spend caps, and it’s the one CodeHerder itself checks against. A new switcher in the app’s top bar moves between the workspaces and groups under the same account without a separate sign-in for each.

Once a task’s pull request is open, nothing else needs to happen until a human reviewer merges it or asks for changes. CodeHerder now has a stage for exactly that wait, await_merge, instead of leaving the task sitting in an earlier stage that implies work is still in progress.

Your git host can tell CodeHerder the moment a pull request merges, through a webhook. If that webhook is not configured, CodeHerder polls the pull request itself on a schedule, so a task doesn’t need a live human watching it to move forward once its request lands.

Setting up a credential an agent needs used to mean switching to the app, even if everything else about the task was happening from the terminal.

ch secrets now covers the same workspace secret store the app’s Secrets page writes to: set a value, list what’s stored, and remove one, all without a browser tab. A secret is referenced by name rather than pasted directly into a launch config, and the underlying value stays write-only the same way it does through the app: nobody reads it back out once it’s saved, through the app or the CLI.

It’s the same store either way, so a secret set from one surface shows up immediately on the other.

CodeHerder mints a scoped credential for each session so an agent can act as itself rather than as a broader identity. Previously that credential stayed valid until something explicitly revoked it, normally when the session ended cleanly, but not if the session crashed or was killed abruptly.

Session-bound credentials now carry a time-to-live in addition to being revoked on a clean exit. One left behind by a session that didn’t shut down properly stops working on its own once its TTL passes, rather than staying valid indefinitely. These credentials are also hardened to stay confined to the task they were minted for.

A device could look online and still fail to run a session: a coding agent that isn’t signed in, a drifted clock, a missing container runtime. Finding out meant waiting for a session to fail and guessing why.

Every device now runs a set of named readiness checks: registration, clock skew against the server, coding-agent sign-in state, container runtime availability where that mode is on, spare session capacity, and an hourly canary spawn proving the device can start a session end to end. The device list shows one health badge rolling all of this up, and expanding it shows exactly which check is failing instead of a vague “unhealthy” status.

Some of these checks are advisory and some are load-bearing: a device whose canary spawn or git credentials are failing stops being picked for new work until it’s fixed, and the reason is named on the device rather than surfacing later as a session that mysteriously stalled. A device that has never reported readiness at all is unaffected and keeps taking work as before.

A dev session that was live when its device rebooted used to just sit there afterward, showing as running when nothing was actually behind it anymore.

CodeHerder now detects when a device has come back up after a reboot and automatically resumes any dev session that was live on it, rather than leaving it stranded in a state nobody’s watching. Stopping, archiving, and resuming a dev session by hand work the same way they always did; this just covers the case where the interruption wasn’t something you chose.

An idle policy complements it: a session that’s been sitting unused for a while parks itself, freeing the device’s capacity for other work, and picks back up cleanly the next time you attach to it.

A workspace’s cost history only grows, and reading it by scanning every raw spend event gets slower the longer a workspace has been running.

The workspace-level cost pages now read from a durable rollup that’s kept up to date as events come in, instead of re-aggregating raw events on every request. Retention for the raw events themselves is configurable separately from the rollup, so a workspace can keep the rollup’s full history while trimming how long the underlying detail is kept around.

The costs pages and ch cost see no change in what they show, only in how quickly the numbers come back once a workspace has months of history behind it.

You can now cap how much a single agent spends in a day, and how much a single task can cost in total, in plain dollars.

Cross either limit and CodeHerder warns you first, so you can see the number climbing before anything stops. Cross it by enough and it stops spawning new work under that cap, so one runaway task or one unexpectedly expensive agent can no longer eat the rest of the day’s budget by itself.

Rebooting or maintaining a device used to mean either waiting for it to happen to go idle, or pulling it out from under whatever it was running.

ch device drain marks a device as closed to new placements without touching what’s already running there: existing sessions keep going until they finish naturally, and nothing new gets staffed to it in the meantime. Once everything has wound down, the device can be taken offline cleanly. ch device undrain puts it back in rotation when you’re done.

It’s a small command, but it turns “take this device down” from a disruptive interrupt into something you can schedule.

A workspace can now store a third-party API key or token as a secret, encrypted at rest, instead of pasting it into a task’s instructions where it sits in plain text forever.

Once stored, a secret is write-only from the app’s point of view: you can replace it or delete it, but nobody can read its value back through the UI or the API. A task references the secret by name, and CodeHerder injects the real value into the agent’s environment only at spawn time, redacting it from any logs the session produces.

CodeHerder used to drive one coding agent harness, Claude Code. It now also spawns and resumes work with Codex, Cursor, and OpenCode, so a device already set up for one of them doesn’t need a second install to join a herd.

Each harness reports its own cost back to CodeHerder in the same currency, real dollars per task, so a workspace running a mix of agents sees one combined cost picture instead of a different number format per tool. Which harness a task uses stays a per-agent, per-device choice: nothing about a task’s brief or its workflow stage changes based on which one picks it up.

Not every reason to run an agent session is a task in the backlog. Sometimes you just want a terminal open against a repo, right now, to poke at something or answer a quick question.

A dev session is exactly that: pick a repo and a device, and CodeHerder provisions a real worktree and drops you into a live agent terminal, with no task to file and close out afterward. It shows up in its own list, separate from task work, with the same attach, stop, and archive controls a task-driven session already has. Stop one and its worktree tears down with it; if you need to pick the same thread back up later, a session can also be resumed rather than started fresh.

The ch dev-session command group covers the same lifecycle from the terminal: create one, list what’s running, attach to it, and stop it, without ever going through a task.

Connecting a third-party account used to be scattered across whichever feature needed it, with its own ad hoc setup each time.

A new Integrations section gives every connection one place to live. GitHub is the first provider, and it can be connected either by pasting a personal access token or by signing in through the browser, whichever fits how your team already works. Once connected, the credential itself is stored write-only: it can be used to act on your behalf, but nobody can read it back out through the app or the API after it’s saved.

The catalog is built to take more providers without a redesign, so a connection you set up once becomes the pattern for whatever gets added to it next.

A workspace with several teams under it used to mean registering the same device, repo, and agent separately in each one, even when they were all meant to share the same setup.

A workspace can now be created as a group: a container that organizes other workspaces beneath it but never owns tasks, sessions, or messages of its own. Anything registered at the group level (devices, repos, agents, teams, and wiki pages) is inherited by every workspace nested underneath, so a device added once at the group is immediately usable by every team below it. The actual work still happens in a leaf workspace; a group is purely the shared shelf above.

Navigation reflects the split too: a group gets its own landing page distinct from a workspace’s task board.

By default, an agent working a stage runs with whatever access the device it’s on has: the same filesystem, the same network reach, the same everything. That’s fine on a device you trust with a specific repo, and more than you want to grant by default on a shared one.

Turning on the Docker executor for a device runs each stage’s agent inside its own container instead, with the sandbox it’s working in and the caches it needs mounted in rather than the whole machine, and separated from the work of every other task on that device. Its outbound traffic leaves through a proxy that always refuses the machine’s own loopback and private-network addresses, the cloud provider’s instance-metadata address, and any connection aimed at a bare IP address instead of a hostname: an agent can reach the public internet, but not the inside of the network the device is sitting on. A device that needs to be tighter than that can be put in a stricter mode where only a named list of hosts is reachable at all. This is opt-in per device, so it doesn’t change behavior anywhere you haven’t turned it on, and it composes with the per-stage write policy that already controls whether a stage can commit at all.

Together, a locked-down device can now bound what an agent can reach as well as what it can write.

Explaining a bug used to mean describing what’s on screen in words, or uploading a screenshot somewhere else and pasting a link back into the task.

Any markdown field on a task now accepts a paste or a drag: a screenshot, a log file, a PDF, whatever’s relevant. It attaches directly to the task, shows up in a list of everything attached, and is readable by whichever agent is working the task, so an agent debugging a UI issue can actually see the screenshot you pasted in, not just a description of it.

Attachments stay scoped to the task they were added to, which keeps them easy to find later and keeps a workspace from accumulating an unsorted pile of uploads with no owner.

Finding something you knew existed, a task from last week, a comment someone left, a line in a help guide, used to mean guessing which section of the app it lived in and browsing there directly.

There’s now one search box in the header at every screen size, open from anywhere in the app. It searches across tasks, messages, comments, and the help centre in one pass, and shows a matched snippet under each result so you can tell which one you meant before opening it. A type filter narrows the results to just one of those categories, and a recently-accessed list gives you a shortcut back to whatever you were just looking at.

It’s a single endpoint under the hood, so results are consistent no matter where in the app you opened search from.

Some work isn’t a one-off; it’s a report someone should always be running, or a check that should happen every week whether or not anyone remembers to file it. Until now, that meant a human filing the same task by hand each time.

A schedule fires on a cron cadence and creates a normal task from it, seeded with whatever fields you set up beforehand. From there it flows through the workflow like any other task. Run one immediately to see what it produces, give it an end date, or disable it without deleting the setup. A guard skips a re-fire while the previous task it spawned is still open, so a slow task doesn’t pile up duplicates behind it.

Both the app and ch schedule cover the full lifecycle: create, list, inspect, and disable.

A task used to need someone to assign it to an agent before anything happened. Now the orchestrator does that itself: an open task gets claimed, an agent gets staffed to it, and the task advances through its workflow as each stage finishes, without a human doing the assigning.

You can still take a device or an agent out of the rotation without deleting it. Disabling one stops it from taking new work immediately, while anything it’s already running keeps going until it finishes. That’s useful for a device you’re about to reboot, or an agent persona you want to pause without losing its history and configuration.

The result is a backlog that keeps moving on its own: file a task, and something starts working it without a second step.

A workflow used to be a fixed sequence of stages that all ran the same kind of agent with the same kind of access. That’s fine when every stage does the same job, and wrong the moment one of them shouldn’t.

Every stage in a workflow now has its own prompt, its own required capabilities, and its own write policy, authored right on the workflow itself. A review stage can be marked read-only, and the device that runs it backs that up rather than leaving it to the prompt: the agent is launched with the push credentials stripped out of its environment and with git-over-ssh offering no key, and its work stays on an isolated branch that reaches your main branch only through an explicit landing step. For a harder boundary, a device can run the agent under its own operating-system account that cannot read the operator’s git credentials at all, and a device that has not been set up that way can be configured to refuse a read-only stage outright rather than start it while a push credential is still readable.

Stages hand off to the next one in sequence, and a task can’t skip ahead in its own pipeline. Combined, this means you can build a workflow where planning is read-only, coding can write, and review is read-only again, with the read-only stages backed by the device’s own credential handling rather than by the prompt alone.

Getting ch onto a new machine used to mean finding the right release and pulling it down some other way. The app now has an Install CLI page that serves the current build directly, matched to your platform, so a new laptop is one download away from a working terminal.

Once it’s installed, ch self-update pulls the latest build in place without a reinstall. The two stay in step: whatever the app is currently serving is what self-update will fetch.

Alongside this, the durable per-task working directory an agent runs in is now called a sandbox everywhere in the product, in the app, the CLI, and the docs, rather than the internal term it used to go by.

Checking a task from a phone used to mean fighting a table built for a wide screen: a horizontal scroller for every list, page headers that wrapped into two lines, and text inputs that zoomed the whole page in the moment you tapped one.

Lists now switch to stacked cards below a certain width, each one showing the same fields a table row would, just arranged vertically instead of squeezed into columns you’d have to scroll sideways to see. Page headers stay on a single row at any width. Tapping into a text field no longer triggers the browser’s auto-zoom, so the layout stays put while you type.

None of this changes what’s on a page, only how it’s laid out once the viewport gets narrow enough that the desktop layout stopped making sense.

Knowing that an agent finished a task is one thing; knowing what it cost to get there is another, and until now that number lived in a workspace-wide total rather than on the task itself.

The task detail page now shows spend for that specific task, attributed to whichever agent was actually working it at the time. The breakdown separates fresh tokens from cached-read and cache-write tokens, so a task that leaned heavily on prompt caching reads differently from one that didn’t: the three classes carry very different prices, and folding them into one number was hiding that.

Historical tasks got the same treatment: cost is backfilled from each task’s own timeline of in-progress stages, not just recorded going forward, so older work shows real numbers too rather than a gap before this shipped.

Getting a teammate into a workspace used to mean handing them an API key out of band and trusting them to keep it somewhere safe. That’s a rough start for anyone joining a team, and an awkward thing to rotate later.

The web app now has a proper sign-in screen: an email address and a password, backed by a hosted identity provider rather than anything CodeHerder stores itself. A new address has to be verified before CodeHerder will trust it, so a typo or an unowned inbox can’t quietly become a login. The terminal got the same upgrade: ch login opens the same flow and stores a session for the CLI, and ch logout closes it out.

An API key hasn’t gone away; it’s still how an agent or an automation authenticates. What’s changed is that a human no longer has to be handed one just to get into their own workspace, and losing a laptop is now a password reset instead of a key rotation across every place that key was ever pasted.