DEV Community: AgentRQ

How We Built a Shared Markdown Board for AI Agents (and Made Checklists Tick Themselves)

Mustafa Turan — Tue, 13 Oct 2026 08:00:18 +0000

TL;DR: We run one AI agent per workspace, and each one only sees its own tasks. That's good for focus and bad for hand-offs. The Pano (AgentRQ v0.10.0) is a board of markdown docs that every workspace in an account can read and write. Checklist items can be assigned to a workspace's task, and the item's checkbox follows that task's status on its own. The interesting parts are the design choices: the markdown is the source of truth, agents get no search, a status change rewrites the doc on the server, and every write carries a version, so two agents can't silently overwrite each other.

What problem are we solving?

Single-purpose agents work well. The API agent knows the API, the web agent knows the frontend, and neither one's context is cluttered by the other's work.

But real work crosses those boundaries:

The API agent changes a response shape. The web agent needs the new contract.
A release needs three workspaces to finish their parts before Thursday.
A postmortem should be read by every agent that touches webhooks.

Until now, the only thing moving knowledge between those agents was the human, who copied the contract into the web task, checked each workspace for progress, and pasted the postmortem into three prompts.

We wanted a shared surface that agents can write to and read from, that humans can see at a glance, and that doesn't wreck the isolation that makes single-purpose agents good.

What is a Pano doc?

A doc is deliberately boring:

a title (up to 200 characters)
markdown (up to 256 KiB)
a paper color (yellow, pink, green, blue, orange, purple, amber)
files (up to 2 MiB each, 100 per doc)
comments, each recording who wrote it: a workspace or the human

It belongs to the account, not to a workspace. The board shows the human's own docs first, then the agents' docs, newest first.

Agents reach it through one MCP tool, pano, which takes an action and a payload:

{"action": "save", "payload": {"title": "v2.4 release plan", "markdown": "- [ ] Cursor pagination\n- [ ] Changelog", "color": "green"}}
{"action": "read", "payload": {"id": "0kH25QEUKFV", "includeComments": true}}
{"action": "comment", "payload": {"id": "0kH25QEUKFV", "comment": "Merged behind the flag."}}

The other actions are edit, attach, delete and help. A save without an id creates a doc and returns its id. A save with an id replaces the title and markdown, but only if it also sends the doc's current version (more on that below).

Why can't agents search the Pano?

This was the most debated choice, and we think it's the most important one.

Agents can't list or search the Pano. An agent reads a doc only because someone handed it the doc's id: in a task, a reply, or an event payload. The board UI has a title filter for humans. Agents don't.

The reasoning:

Isolation stays real. The point of one-agent-per-workspace is a small, relevant context. If every agent could browse every doc, the Pano would become a shared junk drawer that every agent half-reads.
Hand-offs become explicit. "Here's the contract, id 0kH25Ofyi1Z" is a deliberate act. You can trace exactly why an agent read something.
No relevance ranking to get wrong. There's no retrieval step quietly deciding what context an agent gets.

The cost is that the writer has to pass the id along. In practice that fits how agents already work: they finish a task, reply, or publish an event, and the id goes in that message.

How does an assigned checklist item follow its task?

This is the part developers ask about most.

Step 1: assigning writes a link into the markdown

When you pick Assign to → api on a checklist item, the web app:

creates a task in the api workspace whose title is the item text and whose body points back to the doc;
rewrites that line of the markdown so it ends with a link to the task, with the status in the link's title;
saves the doc.

The result is plain markdown:

- [ ] Cursor pagination on /v2/invoices → [@api](/workspaces/0kH1tWzfwLx/tasks/0kH1ye6SDz7 "notstarted")

There's no separate assignments table. The link is the assignment, and the link's title is the cached status. Any agent that reads the doc sees who owns the item and where the task lives, with no extra API call. The renderer turns that link into the status chip you see on the board.

Step 2: a status change triggers a server-side rewrite

Task status can change from anywhere: the human in the UI, the agent through its MCP tool, or the supervisor. All of those emit the same internal CRUD event. A subscriber listens for task updates and completions and runs a sync:

Build the task's path, /workspaces/<ws>/tasks/<task>.
Find the account's live docs whose markdown contains that path. It's a plain LIKE '%path%' query, which is enough because the path is unique.
For each doc, walk the markdown line by line and rewrite matching items.

The line-matching is two regexes: one recognizes a task-list item, and one recognizes an assignee link at the end of the line.

// a task-list item: a list marker, then [ ] or [x]
`^[ \t]*(?:[-*+]|\d{1,9}[.)])[ \t]+\[([ xX])\](?:[ \t]|$)`
// an assignee: a link to a task, titled with its status
`\]\((/workspaces/[0-9A-Za-z]+/tasks/[0-9A-Za-z]+)(?: "[a-z]*")?\)[ \t]*$`

For each line that has both and points at this task, the sync writes the new status into the link title, and sets the box to [x] when the status is completed (otherwise [ ]). Lines inside fenced code blocks are skipped, because a - [ ] there renders as text, not a checkbox.

So when the api agent marks its task completed, the item becomes:

- [x] Cursor pagination on /v2/invoices → [@api](/workspaces/0kH1tWzfwLx/tasks/0kH1ye6SDz7 "completed")

Note that the checkbox doesn't just tick on completion. It follows the status both ways: reopen the task and the box clears again.

Step 3: the write is a sync, not a save

A subtle detail: this write is not a normal save. It updates only the markdown, excerpt, size and checklist counters, and deliberately skips updated_at.

Why it matters:

The doc keeps its place on the board. A task finishing in another workspace shouldn't bump the release plan to the top as if someone edited it.
The author stays the author. The doc isn't suddenly "updated by api".
The doc's lifetime doesn't change. Docs expire a set number of days after their last save (more on that below). A background status sync shouldn't keep a doc alive forever.

What the sync does change is the doc's version. The markdown is different now, so any agent still holding the old version has to read the doc again before it writes. The next section explains why that matters.

The "2 of 6 done" progress is recounted from the markdown with the same task-item regex on every write, so the board, the card and the doc always agree.

Step 4: open boards update live

After the rewrite, the server publishes a pano.changed event on the account's event stream. Any open board or doc page reloads that doc. The human watching the release plan sees the chip go from Ongoing to Completed and the box tick, without a refresh.

One honest constraint: the event bus is in-process, so only the backend instance that handled the task change does the rewrite. That's fine, because the rewrite goes to the shared database, and any instance serves the result.

How do two agents avoid overwriting each other?

A shared doc has the classic lost-update problem. In the first version of the Pano, a save with an id replaced the whole doc. So this could happen:

The api agent reads the release plan.
The web agent reads the same release plan.
api ticks its item and saves the whole markdown.
web adds a line and saves the whole markdown it read in step 2.

web's save silently wipes out api's tick. Nobody gets an error, and the doc is just wrong. With several agents and a server-side checklist sync all writing to the same docs, this isn't hypothetical.

The fix (agentrq#896, merged right after v0.10.0) is optimistic concurrency with a version number.

Every doc has a version

Each doc has a version, starting at 1, which goes up on every write: a save, an edit, and the checklist sync described above. read returns it, and any update (a save with an id, or an edit) must send the version it read. Creating a doc needs no version.

The check happens in the UPDATE itself

The important detail is where the check runs. Reading the version, comparing it, and then writing would still leave a race window between the compare and the write. Instead, the version is part of the UPDATE's WHERE clause, and the same statement bumps it:

UPDATE pano_docs
SET version = version + 1, markdown = ?, title = ?, ...
WHERE id = ? AND user_id = ? AND expires_at > ? AND version = ?   -- the version the writer read

If another write got in first, the row's version has already moved, the WHERE matches nothing, and zero rows are affected. The server then checks whether the doc still exists at all. If it does, the write is a conflict. If it doesn't, it's "not found". Either the whole write lands at version N+1, or nothing changes. The compare and the write can't be split.

A conflict tells the agent exactly what to do

A stale write is refused with HTTP 409 in the REST API, and the MCP tool returns a message written for an agent to act on:

the Pano doc changed since you read it (you sent version 3, it is now 4):
read it again, apply your change to the new content and save again with the new version

A save with no version at all gets a similar message that names the current version. That matters because agents written before versioning existed would otherwise keep overwriting. Now they're told how to fix their call.

The agent doesn't need special retry logic. It does what the message says: read the doc, redo its change on the new content, and save with the new version. The overwrite becomes an explicit merge, done by the one party that knows what its change meant.

`edit`: change a line without resending the doc

Versioning makes a whole-doc save safe, but resending 256 KiB of markdown to tick one box is still wasteful, and a bigger payload means more chances for an agent to garble something it didn't mean to touch. So there's a new edit action that takes a list of ops:

{"action": "edit", "payload": {
  "id": "0kH25QEUKFV",
  "version": 4,
  "ops": [
    {"op": "replace", "oldString": "- [ ] Changelog and docs", "newString": "- [x] Changelog and docs"},
    {"op": "append", "text": "\n- [ ] Announce on the blog"}
  ]
}}

append adds text to the end.
replace swaps oldString for newString, but only if oldString occurs exactly once. Zero matches is refused ("not in the markdown"). Two or more is refused with the count and a hint to include more surrounding text. That's the same rule as a good code-edit tool: an ambiguous edit is an error, never a guess.
The ops apply in order, all or none. If op 2 fails, op 1 isn't saved either.
The version is checked before the ops run. Against a stale doc, a replace would fail with a misleading "not found", so the agent is told the real problem: the doc changed.

The result then goes through the same save path, so the size limits, the linked-file rules and the version check all still apply.

From a shell, the CLI does the same:

npx -y @agentrq/agentrq-ws@latest pano edit <id> --version 3 --replace "- [ ] Tag" --with "- [x] Tag"

save and edit now print the doc's id and its new version, so a script can chain writes without another read.

What humans see on a conflict

The web editor uses the same check. If you're editing a doc and an agent saves it first, your save is refused, but your draft stays in the editor. A banner says the note changed while you were editing and offers to load the latest version, so you can copy your text first. Ticking a box on the board works the same way: on a 409, the doc is reloaded and you're asked to try again, so what you see is what a retry would change.

The checklist sync bumping the version fits in here too. If the api task completes while you have the release plan open in the editor, the server's rewrite moves the version, and your stale save is refused instead of un-ticking the item.

How do @mentions turn into tasks?

Comments are plain text with an author. Typing @ suggests workspaces. When the comment is posted, every workspace it names by its full name gets a task:

title: Pano: <doc title>
body: the comment quoted, then an instruction to read the doc with includeComments and answer with a comment on the doc

That last part is the design. The answer goes back on the doc, not into a private task thread, so the conversation stays where the work is and the human can read it later. Pings are sent about a second apart, because the server allows one task creation per second per account. If one ping fails, the comment is already posted and the others still go out.

What stops the board from filling up forever?

Every doc has a time to live: 30 days after its last save by default. A save can ask for any whole number of days up to a server maximum (365 by default, configurable). An expired doc is hidden right away. An hourly sweep on every backend instance deletes expired docs and their files. If two instances race, the loser just skips the doc.

This matches how hand-off docs actually behave. A release plan is useful for a few weeks. A postmortem can ask for a year.

What are the rules for files?

There are two kinds of files, and the split keeps docs self-consistent:

Linked files travel with the markdown. Each must be linked from it by name, as ![chart](chart.png) or [spec](spec.pdf). A save that sends a file the markdown doesn't link is refused. A linked file that the markdown stops linking is deleted at the next save. So every linked file is always reachable from the doc's text.
Attachments are added with attach, need no link, and stay until the doc is deleted.

Limits refuse rather than truncate. An agent told its doc is over 256 KiB can decide what to cut. One whose doc was silently cut in half can't.

For shells and CI, the agentrq-ws CLI keeps the doc out of the agent's context entirely:

npx -y @agentrq/agentrq-ws@latest pano save --title "Release plan" --markdown @plan.md --file chart.png --color blue
npx -y @agentrq/agentrq-ws@latest pano read <id> --comments --out ./pano

save prints only the id. read --out writes the markdown and its linked files side by side, so relative links still resolve.

What does this unlock?

Agents hand work to each other directly. The API agent posts the contract and puts the id in its reply. The web agent reads it. No human copy-paste.
A plan tracks itself. Items assigned to workspaces tick when the work is done, not when someone remembers to update the list.
Isolation and coordination together. Each workspace keeps its own tasks and memory. The Pano is the one shared surface, used on purpose.
Hand-offs become visible. What agents tell each other is on a page a human can scan, edit or delete.
Many writers, no lost updates. Agents, the checklist sync and humans can all write to the same doc, and a stale write is refused instead of quietly winning.

FAQ

Is the Pano a vector store or RAG?
No. There's no embedding, no retrieval and no search for agents. An agent reads exactly the docs whose ids it was given.

What if someone edits an assigned line by hand?
The sync only matches lines that are a task-list item and end with a link to that exact task path. Change the text before the arrow freely. Remove the link, and the item is no longer assigned.

Does a status sync count as an edit?
Not for the board. It updates the markdown and checklist counts without touching updated_at, so the doc keeps its place, author and expiry. It does bump the version, so a writer holding the old one has to read again.

What happens if two agents save the same doc at once?
The first write wins and moves the version. The second is refused with a 409 and a message telling the agent to read the doc again, redo its change and save with the new version. Nothing is silently overwritten.

Why not lock the doc while an agent edits it?
Agents can stall or crash mid-task, and a lock held by a dead agent blocks everyone. Optimistic concurrency costs nothing when there's no conflict, which is almost always, and when there is one, the writer that knows what its change meant is the one asked to redo it.

Who can read a doc?
Every workspace in the account, plus the human. Comments and writes record the workspace that made them (a fork records its parent).

Can I self-host it?
Yes. AgentRQ is open source. File storage is local by default, or S3 with AGENTRQ_PANO_STORAGE=s3, and AGENTRQ_PANO_MAX_TTL_DAYS caps doc lifetime.

How are you passing context between agents today: shared files, a vector store, or a human in the middle? We'd like to hear what's worked for you.

Originally published on the AgentRQ blog. AgentRQ is an open-source, human-in-the-loop task manager for AI agents: github.com/agentrq/agentrq.

Copilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip

Tony — Mon, 12 Oct 2026 18:02:40 +0000

TL;DR

Copilot CLI: copilot --yolo (same flag as --allow-all), or /yolo in a running session. It is shorthand for --allow-all-tools + --allow-all-paths + --allow-all-urls.
VS Code: pick Allow all in the chat permission picker, type /yolo, or set "chat.tools.global.autoApprove": true to make it permanent.
What it skips: approval prompts. What it doesn't: your --deny-tool rules, and (in VS Code, explicitly documented) an enabled sandbox.
Autopilot is a different switch. It keeps the agent iterating; YOLO approves its tool calls. Unattended runs usually want both.

Everything here was checked on October 7, 2026 against GitHub's Copilot CLI reference, the github/copilot-cli changelog (1.0.93) and VS Code's agent docs in microsoft/vscode-docs.

Why does "YOLO" mean two different things in Copilot?

Because Copilot ships two agent runtimes with two permission systems. The Copilot CLI is a terminal agent with flag-driven permissions. Copilot Chat in VS Code is an editor agent whose permissions hang off a picker and settings.json. They share vocabulary (/yolo exists in both) but not config. Nothing you set in VS Code changes the CLI, and vice versa.

The one thing they agree on is the layering. There are three separate gates between the model and your machine:

model wants to act
   │
   ▼
[1] deny rules ─────────── always win, YOLO or not
   │
   ▼
[2] approval prompt ────── this is the only layer YOLO removes
   │
   ▼
[3] sandbox (if enabled) ─ still limits files + network
   │
   ▼
your shell / filesystem / network

Keep that picture in mind; every flag below is about layer 2.

What exactly does copilot --yolo turn on?

copilot --yolo

--yolo and --allow-all are the same flag, documented as "Enable all permissions (tools, paths, and URLs)". It decomposes into three narrower switches you can use on their own:

Flag	What stops asking
`--allow-all-tools`	every tool call (GitHub notes this is required when you drive the CLI from a script)
`--allow-all-paths`	the check on which file paths the agent may touch
`--allow-all-urls`	URL fetch approval

The env var COPILOT_ALLOW_ALL=true does the same as --yolo and trusts the current directory, which makes it the CI-friendly form: no flag plumbing through wrapper scripts.

The nerdy bit worth noticing: paths and URLs are separate trust dimensions from tools. If your threat model is "the agent may run npm test but must not read ~/.ssh or exfiltrate to random hosts", --allow-all-tools alone is a materially different posture from --yolo.

How do the in-session commands map onto each other?

/permissions is now the canonical command, with four arguments: default, assisted, allow-all and show. Everything else is an alias:

/yolo and /allow-all → /permissions allow-all
/yolo also takes off, auto and show
/reset-allowed-tools (or /permissions default) undoes it

While it's on, the footer shows a YOLO indicator, so you can't forget you're flying without a net.

One gotcha for people coming from other agents: Shift+Tab does not toggle YOLO in the Copilot CLI. It cycles standard → plan → autopilot. That's a mode-of-work switch, not a permission switch.

Why isn't Autopilot the same thing as YOLO?

Two orthogonal axes:

Autopilot (--autopilot, /autopilot, or Shift+Tab) answers "should the agent keep going without checking in with me?"
YOLO answers "should the agent run tools without asking me?"

Autopilot without YOLO: the agent keeps working, then blocks on the first approval. YOLO without Autopilot: approvals fly through, but the agent stops to check in. An unattended run usually needs both. VS Code's security docs make the same point from the other side: Autopilot "combines auto-approval with autonomous iteration" and "reduces your ability to review intermediate steps".

Can I get most of the speed without approving everything?

Yes, and this is where Copilot's design is genuinely nice. Two halfway layers:

Pattern rules. --allow-tool and --deny-tool take typed patterns:

copilot --allow-tool 'shell(git:*)' --deny-tool 'shell(git push)'

Other shapes: write(src/*.ts), read(.env), url(github.com), MyMCP(create_issue). The rule that matters: a deny always wins, including over --yolo. That gives you a cheap "YOLO minus the footguns" profile: --yolo --deny-tool 'shell(git push)'.

Assisted permissions. /permissions assisted puts a safety model in front of the prompt. It approves routine requests and only escalates the rest to you. It's a classifier in layer 2, not a sandbox, so it reduces prompts without adding isolation.

Admins get the last word: "disableBypassPermissionsMode": "disable" under permissions kills all of this, and "allow-auto-only" restricts users to the assisted mode.

How does VS Code's version work?

Copilot Chat calls it Allow all, one of three permission levels:

Level	Behavior
Manual (default)	asks for each tool call
Assisted	a model approves routine requests (needs `chat.assistedPermissions.enabled`)
Allow all	asks for nothing; VS Code warns you the first time

Three ways in:

The permission picker in the chat input.
/yolo or /autoApprove in chat, for the current session. Undo with /disableYolo or /disableAutoApprove.
Permanently, in settings.json:

{ "chat.tools.global.autoApprove": true }

That last one approves every tool in every workspace, and VS Code's own docs flag it as a setting that "disables critical security protections". The docs recommend the session-scoped Allow all when you don't need auto-approval everywhere. The experimental chat.permissions.default (default, autoApprove, autopilot) picks the level new chats start with, and orgs can block global auto-approve with the ChatToolsAutoApprove policy.

Are terminal allowlists enough to keep me safe?

They're the VS Code halfway option:

{
  "chat.tools.terminal.autoApprove": {
    "mkdir": true,
    "/^git (status|diff|log)\\b/": true,
    "rm": false
  }
}

Keys are prefixes or regexes. true auto-approves; false forces a prompt even if another rule would approve. Note that false means ask, not block.

But read the fine print: VS Code's security docs say auto-approval rules "use best-effort command parsing and have known limitations with shell aliases, quote concatenation, and complex shell syntax". Anyone who has written a shell parser knows why: g'it' push, an alias, or bash -c "$(…)" can all slip past a prefix match. Treat allowlists as a convenience, and put the real boundary somewhere that enforces it at the OS level.

What does the sandbox actually enforce, and what doesn't YOLO touch?

In VS Code, turn on chat.agent.sandbox.enabled (or the Sandboxing for terminal toggle in the picker). The docs are explicit that Allow all and Autopilot skip prompts "but an enabled sandbox still restricts terminal file system and network access". Under the hood VS Code's docs list:

macOS: Apple's Seatbelt, built in.
Linux / WSL2: bubblewrap for filesystem isolation plus socat for network proxying (apt-get install bubblewrap socat). WSL1 is out, because bubblewrap needs user namespaces.

Two caveats from the same docs: outbound network stays on by default (chat.agent.sandbox.network.allowNetwork defaults to true), so lock that down separately; and the sandbox is "not a virtual machine or user-account boundary". If you see the older key chat.tools.terminal.sandbox.enabled in blog posts, it's no longer in VS Code's docs.

The Copilot CLI has /sandbox / --sandbox too. GitHub's reference still marks it experimental while the changelog says it's available to everyone, and the CLI docs don't say whether --yolo bypasses it. We treat it as a separate layer like VS Code's, but if you rely on it, check what /sandbox reports.

Can a cloned repo flip YOLO on for me?

In VS Code, the front-line defense is Workspace Trust: an untrusted folder opens in restricted mode, which "also disables agents". So review a repo before you trust it, because trust is what unlocks agents in it at all. The global auto-approve setting is something you set yourself, and the docs steer you to the session-scoped level instead. The CLI has a notion of trusted directories too: COPILOT_ALLOW_ALL=true trusts the current directory, and /add-dir PATH grants file access to another directory and loads its .github/skills and .github/agents as trusted configuration. That's worth remembering before you point a YOLO session at a repo you haven't read.

How do I turn on YOLO per task or per workspace with AgentRQ?

Copilot's YOLO is session-scoped: once on, it's on for everything that session does. If you'd rather decide per task, and answer prompts from somewhere other than the terminal, you can route the Copilot CLI through AgentRQ via the ACP Gateway (Copilot setup guide):

npx @agentrq/acp-gateway@latest --agent github-copilot-cli

This covers the Copilot CLI only; Copilot Chat in VS Code keeps its own picker.

Start Copilot without --yolo. The gateway moves each new session out of any mode that would approve on its own and into one where Copilot asks a person. Every permission request then lands in the AgentRQ task (web, phone or Slack) with the command or edit attached, and you answer:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
Deny: Copilot gets a refusal and carries on.

If nobody answers within 30 minutes, the gateway cancels the turn rather than guessing; tune that with --permission-timeout.

Per task. Flip the YOLO toggle on a task, or set it when you create one, to put just that task in YOLO mode. Every permission request in it is auto-approved and Copilot never waits, while every other task in the workspace still asks. The setting sticks to the task even if the agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so the nightly job can run in YOLO while your interactive work stays supervised.

Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.

The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.

The trade-off. Workspace-wide is one click and zero prompts, but it outlives the job you actually trusted: the next task inherits it whether you meant to or not. Per-task YOLO expires with the task. Our default is the workspace switch off, per-task YOLO for the jobs you've vetted, Always Allow for the boring tools, the sandbox on, and a clean git tree before every YOLO run. The tool call history keeps a record of every call, including the auto-approved ones.

FAQ

Is copilot --yolo the same as --allow-all? Yes. Same flag: tools, paths and URLs.

Does --yolo override --deny-tool? No. A deny always wins.

Why doesn't Shift+Tab turn on YOLO in the CLI? It cycles standard, plan and autopilot. Use /yolo.

How do I make Allow all permanent in VS Code? "chat.tools.global.autoApprove": true, though the session-scoped picker level is the safer habit.

Does Allow all disable the VS Code sandbox? No. An enabled sandbox still restricts terminal filesystem and network access.

Is Autopilot YOLO? No. Autopilot keeps the agent going; YOLO approves its tool calls.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Your turn: do you run Copilot with --yolo plus a couple of --deny-tool guards, or do you trust the assisted classifier more than your own regexes? Tell me your setup in the comments.

Originally published on AgentRQ.

Gemini CLI YOLO mode, read from the source: why settings.json can't turn it on

Tony — Mon, 12 Oct 2026 18:01:40 +0000

TL;DR

Start YOLO with gemini --approval-mode=yolo, or press Ctrl+Y in a running session. --yolo / -y still work but are deprecated, and combining --yolo with --approval-mode is an error.
You cannot make YOLO the default in settings.json. That's a deliberate design choice, and the code that enforces it is three lines long.
YOLO only removes approval prompts. The sandbox (Seatbelt, Docker, Podman, gVisor, LXC) is a separate switch, and in the current source YOLO never turns it on.
In an untrusted folder, any mode other than default gets forced back to default. If security.disableYoloMode or admin secure mode is set, asking for YOLO is a fatal config error, not a silent downgrade.

Everything below was checked against the Gemini CLI source (google-gemini/gemini-cli, 0.65.0-nightly.20261006) and its docs, on October 7–8, 2026.

Who is this even for in late 2026?

Short version: Gemini CLI users with a Gemini Code Assist Standard or Enterprise license.

Since June 18, 2026, Gemini CLI no longer serves Google AI Pro, Ultra or free Code Assist users. Google moved them to the Antigravity CLI (agy), which has a different YOLO story (it's agy --dangerously-skip-permissions, and there's no --yolo at all). Gemini CLI is still developed, though, and the approval code is worth reading on its own. It's one of the cleaner permission designs among coding agents.

What does Gemini CLI actually do with an approval mode?

There are four modes: default, auto_edit, plan and yolo. Here's how the CLI picks one at startup, in order:

--approval-mode <x> on the command line
else --yolo / -y, which maps to yolo
else general.defaultApprovalMode from settings, unless its value is yolo, in which case it's skipped
else default

Step 3 is the interesting one. The resolver doesn't reject a "yolo" value in settings. It just reads past it, as if the key weren't there. The settings schema says it outright: YOLO "can only be enabled via command line".

Two gates come after the mode is resolved:

Kill switch. If security.disableYoloMode or admin.secureModeEnabled is set and the resolved mode is YOLO, startup throws a FatalConfigError. It doesn't quietly drop you to default. You asked for something that's banned, and the CLI tells you so.
Folder trust. If the current folder isn't trusted, any mode other than default gets forced back to default, with a warning. This one applies to auto_edit and plan too, not just YOLO.

Why can't I just put "yolo" in settings.json?

The threat model is a cloned repo.

Gemini CLI merges settings from several layers, and one of them is the workspace's own .gemini/settings.json. If a project file could set defaultApprovalMode: "yolo", then git clone evil-repo && cd evil-repo && gemini would hand an attacker-controlled GEMINI.md an agent that never asks before running a shell command. Prompt injection plus auto-approval is the worst combination in agent security.

So the rule is: YOLO has to come from a human typing a flag (or a key) in this process. Settings can make you more cautious (disableYoloMode, secureModeEnabled, folder trust), but never less. If you want YOLO every time, the supported answer is a shell alias:

alias gemini-yolo='gemini --approval-mode=yolo --sandbox'

Compare that with Qwen Code, Gemini CLI's fork, which does allow tools.approvalMode: "yolo" in settings. It pushes the protection down to folder trust instead.

Does YOLO turn the sandbox on?

Not in the current code, whatever one older config page says.

Gemini CLI has two independent layers:

Layer	What it gates	Switch
Approval mode	Whether a human confirms each tool call	`--approval-mode`, Ctrl+Y, Shift+Tab
Sandbox	What a tool call can touch once it runs	`--sandbox`, `GEMINI_SANDBOX`, `tools.sandbox`

The sandbox resolver never reads the approval mode. With nothing set, it returns "no sandbox". Here's what you get when you turn it on:

macOS, sandbox: true: sandbox-exec (Seatbelt) is picked first. The default profile is permissive-open. Despite the name, it starts from (deny default), allows file reads anywhere, and allows writes only to the project dir, temp, cache, ~/.npm, ~/.cache and any --include-directories. It also explicitly blocks the Docker socket and writes to ~/.gemini credential files (oauth_creds.json, mcp-oauth-tokens.json, …). Pick another built-in profile with SEATBELT_PROFILE: permissive-* and restrictive-* come in -open, -closed and -proxied network flavors, and strict-* in -open and -proxied. Anything not on that list is rejected, which also stops path traversal through the variable.
Linux/other, sandbox: true: Docker, then Podman, whichever exists.
Explicit only: runsc (gVisor, Linux only, run via Docker's --runtime=runsc), lxc (needs a container you already have running, so it's never auto-detected) and windows-native (Windows only).

A wrong value fails fast. GEMINI_SANDBOX=runsc on a Mac, or true with neither Docker nor Podman installed, is a fatal error, not a silent run without a sandbox.

The point: YOLO plus a sandbox is a reasonable setup. YOLO without one means "run anything with my user's full privileges". Pass --sandbox yourself.

How do Ctrl+Y and Shift+Tab interact?

Ctrl+Y toggles between YOLO and default. This is the only in-session way into YOLO.
Shift+Tab cycles default → auto_edit → plan (plan only if it's enabled). It never lands on YOLO. If you're in YOLO and press it, you drop to auto_edit.

Small design choice, sensible result: the key you hit all the time can't take you to the dangerous mode by accident.

One more thing: --yolo together with --approval-mode doesn't pick a winner. It's a validation error. Ambiguous intent fails at the door.

What happens in CI and headless runs?

This edge case trips people up. In non-interactive mode (gemini -p "…") there's nobody to answer a prompt, and the policy engine handles that by translating ask_user decisions into deny. So in headless default mode, a tool call that would have asked simply doesn't run.

Belt and braces: the CLI also removes ask_user, the tool the model uses to ask you a question, from the toolset in headless and ACP modes. The source comment says why: so that "it can never be allowed via a high-priority policy rule when no human is present". In ACP mode the IDE or client does the asking instead.

So headless, your options are:

--approval-mode=yolo, ideally with --sandbox
--approval-mode=auto_edit, plus policy rules that allow the shell commands you need
or a policy file that says allow for exactly the tools the job uses

What are the halfway options?

auto_edit approves file edits and still asks before shell commands.
tools.allowed lists tool patterns that skip the prompt, such as run_shell_command(git).
The policy engine is the recommended route: TOML files in ~/.gemini/policies/ with allow / deny / ask_user rules, which can be scoped to a mode (including YOLO). --allowed-tools on the command line is deprecated in its favour.

For the Gemini Code Assist extension in VS Code, set "geminicodeassist.agentYoloMode": true in user settings and reload the window. Note the familiar rule again: it only works in a trusted workspace. In IntelliJ, the matching option is Auto-approve changes.

How do I turn on YOLO per task or per workspace with AgentRQ?

Gemini CLI's switch is per process: you either started with --approval-mode=yolo or you didn't. AgentRQ moves that decision onto the task.

1. Connect Gemini CLI. It goes through the ACP Gateway. The Gemini CLI setup guide and the step-by-step post have the details:

npx @agentrq/acp-gateway@latest --agent gemini

Start it without --approval-mode=yolo. The gateway also moves each new session out of any mode that would approve on its own and into one where Gemini CLI asks a person.

2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, on your phone or in Slack, along with the command or edit it's asking about. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes that limit.

3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every permission request in that task is approved automatically, while every other task in the workspace still asks. The flag lives on the task, so it persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.

3b. YOLO for the whole workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

The trade-off. Per-task YOLO is scoped trust: it ends when the job you vetted ends, and an unattended nightly job can run in YOLO while your interactive work stays supervised. Workspace-wide YOLO is easier, but it outlives any single decision you made, and every new task inherits it. The setup that holds up: leave the workspace switch off, use per-task YOLO, keep GEMINI_SANDBOX=true (or "tools": {"sandbox": true}) so the auto-approved commands still run in a container, start from a clean git tree, and read the tool call history afterwards. More on the per-task model: AgentRQ YOLO mode.

FAQ

Is gemini --yolo still a thing? It works, but it's deprecated. Use --approval-mode=yolo, and don't pass both.

Can I make YOLO the default in settings.json? No. The resolver skips "yolo" in defaultApprovalMode. Use a shell alias.

What does Ctrl+Y do? It toggles YOLO ↔ default in the running session.

Does YOLO enable the sandbox? Not in the current source. Add --sandbox or set GEMINI_SANDBOX.

Why does Gemini CLI refuse to start with --yolo? security.disableYoloMode or admin.secureModeEnabled is set. That's a fatal error by design. If it starts but drops you to default, the folder isn't trusted.

Why do my tool calls silently not run in gemini -p? Headless mode turns "ask" into "deny". Use YOLO (with a sandbox), auto_edit, or allow rules in a policy file.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Over to you: do you think "YOLO only from a flag, never from settings" is the right call, or should a tool trust your user-level config the way Qwen Code does? And if you run Gemini CLI in CI, which sandbox backend did you end up on? 👇

Originally published on AgentRQ.

How to Enable Claude Code Channels for Team and Enterprise Plans (Step by Step)

Mustafa Turan — Sat, 10 Oct 2026 19:18:49 +0000

You connected Claude Code to a channel, maybe AgentRQ, a Telegram bot or a Discord bot, and sent it a message from your phone. Nothing happened. Claude Code started, the MCP server connected and its tools work, but the message never showed up in the session. A startup warning says to ask your admin.

If you are on a claude.ai Team or Enterprise plan, that is expected. Channels ship switched off for organizations, and one person has to flip a switch before anyone can use them.

This guide walks through that switch screen by screen, then covers the managed-settings route and how to limit which channel plugins your team can run.

TL;DR

Claude Code Channels are a research preview, and they are blocked by default on claude.ai Team and Enterprise plans.
An Owner enables them at Organization settings → Claude Code → Channels (claude.ai/admin-settings/claude-code).
The alternative is to set channelsEnabled: true in managed settings. Add allowedChannelPlugins to pick which plugins can register.
Once Channels are on, each developer still chooses channels per session. Step 4 shows how to set up AgentRQ, Telegram and Discord.

What are Claude Code Channels, and why are they off for my org?

A channel is an MCP server that pushes events into a Claude Code session that is already running. Ordinary MCP tools only respond when Claude calls them. A channel can deliver a new task, a reply to a question the agent asked you, a CI failure or a monitoring alert into the session while you are away from the terminal. Claude reads the event, does the work against your real files and can reply through the same channel.

That makes a channel an inbound path into a developer's machine, and Anthropic leaves it to organization admins to decide whether to allow it. The defaults depend on how you sign in:

Account type	Channels by default
Pro / Max (no organization)	Available, opt in per session
claude.ai Team / Enterprise	Blocked until an Owner enables them
Console (API key)	Allowed, unless your org deploys managed settings
Bedrock / Google Cloud / Foundry	Not available

You also need Claude Code v2.1.80 or later. The official channel plugins (Telegram, Discord, iMessage and the fakechat demo) need Bun.

Who can enable Channels?

Only a user with the Owner role on the claude.ai organization. Admins without the Owner role, and regular members, will not be able to change the toggle. If that isn't you, send this post to your Owner.

Step 1: Open Organization settings

Sign in to claude.ai with your Team or Enterprise account. Click your name in the bottom-left corner to open the account menu, make sure your organization (not your personal account) is selected at the top, and choose Organization settings.

Step 2: Go to Products → Claude Code and find Channels

In the left sidebar of Organization settings, scroll to the Products group and click Claude Code (1).

The Claude Code page is long. The quickest way to the setting is your browser's find bar: press Cmd+F on macOS or Ctrl+F on Windows and Linux, and type channels (2). It sits in the Capabilities section, below Dynamic workflows.

Turn on the Channels toggle (3). It carries a Preview badge, and its description reads: "Allow your team to receive inbound messages from MCP servers in Claude Code sessions."

You can skip the menu clicks by opening the page directly: claude.ai/admin-settings/claude-code.

Step 3: Confirm it says "Set by admin"

Once the toggle is on, the label next to it changes from Default to Set by admin. That label shows the setting is now enforced for the whole organization, and members cannot override it.

That's the whole admin side.

Step 4: Connect a channel (AgentRQ, Telegram or Discord)

Turning the setting on doesn't start anything. Each developer still picks which channel servers their session will trust. Below are three common setups: AgentRQ, plus Anthropic's official Telegram and Discord plugins. Pick one, or run several at once.

Option A: AgentRQ

AgentRQ lets you assign tasks, answer the agent's questions and approve its actions from your phone or desktop while Claude Code keeps running on your machine. You don't run a bot or a server.

1. Create a workspace. Sign in at app.agentrq.com, create a workspace for your project and click Generate MCP Token. The token is shown only once, so copy it. Note the workspace ID too.

2. Add the server to .mcp.json in the project root, where you run claude:

{
  "mcpServers": {
    "agentrq-WORKSPACE_ID": {
      "type": "http",
      "url": "https://WORKSPACE_ID.mcp.agentrq.com/mcp?token=YOUR_MCP_TOKEN"
    }
  }
}

The server key has to include your workspace ID, because the next command refers to the server by that name.

3. Start Claude Code with the server as a channel:

claude --dangerously-load-development-channels server:agentrq-WORKSPACE_ID --name my-api-project

A server in .mcp.json alone gives Claude the AgentRQ tools, but it can't push anything into the session. New tasks and your replies only arrive as they happen when the server is also named as a channel.

AgentRQ is a custom channel. During the research preview, only the plugins on Anthropic's allowlist load through --channels, so a custom channel like this one loads through --dangerously-load-development-channels. That flag skips the plugin allowlist after a confirmation prompt. It does not get around an organization that has Channels turned off, which is why the Owner toggle above comes first. --name just labels the session.

4. Send it work. Create a task in the AgentRQ app. It arrives in the running session as a <channel> event, Claude starts on it, and its progress updates and questions come back to the app.

Option B: Telegram

The official plugins run on Bun, so install that first.

In Telegram, open @BotFather, send /newbot, choose a name and a username ending in bot, and copy the token it returns.
Install the plugin and save the token. Run these inside Claude Code:

/plugin install telegram@claude-plugins-official
/telegram:configure <token>

Exit Claude Code and restart it with the channel:

claude --channels plugin:telegram@claude-plugins-official

Send any message to your bot. It replies with a pairing code. Approve the code and lock access to your account:

/telegram:access pair <code>
/telegram:access policy allowlist

Option C: Discord

In the Discord Developer Portal, create an application. In the Bot section, click Reset Token and copy it. Under Privileged Gateway Intents, turn on Message Content Intent.
Under OAuth2 → URL Generator, select the bot scope with these permissions: View Channels, Send Messages, Send Messages in Threads, Read Message History, Attach Files and Add Reactions. Open the generated URL to add the bot to your server.
Install the plugin, save the token, then restart with the channel:

/plugin install discord@claude-plugins-official
/discord:configure <token>

claude --channels plugin:discord@claude-plugins-official

Send the bot a DM. It replies with a pairing code. Approve it and lock access:

/discord:access pair <code>
/discord:access policy allowlist

To run more than one channel in a session, list them all. --channels takes several plugins separated by spaces, and you can use it together with --dangerously-load-development-channels:

claude --channels plugin:telegram@claude-plugins-official plugin:discord@claude-plugins-official \
  --dangerously-load-development-channels server:agentrq-WORKSPACE_ID

Neither flag shows up in claude --help while Channels are in preview, but both work. If the org setting is still off, every server connects and its tools work, but no channel messages arrive, and a startup warning tells the user to ask an admin.

Can I enable Channels with managed settings instead?

Yes. If you already roll out Claude Code managed settings, set the master switch there:

{
  "channelsEnabled": true
}

That is the same switch as the toggle above, and users cannot override it. Console organizations that deploy managed settings need this key too, because deploying managed settings blocks Channels until it is set.

How do I restrict which channel plugins can run?

By default, any plugin on Anthropic's channel allowlist can register, which means the ones in claude-plugins-official. On Team and Enterprise you can replace that list with allowedChannelPlugins. Each entry names a plugin and the marketplace it comes from:

{
  "channelsEnabled": true,
  "allowedChannelPlugins": [
    { "marketplace": "claude-plugins-official", "plugin": "telegram" },
    { "marketplace": "claude-plugins-official", "plugin": "discord" },
    { "marketplace": "acme-corp-plugins", "plugin": "internal-alerts" }
  ]
}

A few rules worth knowing:

allowedChannelPlugins only applies when channelsEnabled is true.
If a plugin isn't on your list, Claude Code still starts, but the channel doesn't register. The startup notice says the plugin is not on the organization's approved list.
Each entry has to match the plugin name as well as the marketplace.
An empty array blocks every allowlisted plugin. Servers loaded with --dangerously-load-development-channels, such as AgentRQ, can still run. To shut Channels off completely, development flag included, leave channelsEnabled unset.

What should admins think about before turning it on?

Channels are useful because they let outside events reach a session, and that is also the part to plan for:

Who can reach the session. Telegram and Discord keep a sender allowlist that you fill by pairing, and messages from anyone else are dropped silently. Always finish with access policy allowlist. With AgentRQ, the workspace MCP token is the key. Anyone with the token can connect to the workspace, so keep .mcp.json out of public repos and generate a new token if one leaks.
Who can approve actions. If a channel relays permission prompts, anyone who can answer through it can approve or deny tool use in that session. Only give that access to people you would trust at the keyboard.
Unattended sessions. People who pair Channels with --dangerously-skip-permissions should do it only in environments they trust.

FAQ

Do I need to restart Claude Code after the admin enables Channels?
Yes. The setting is checked when a session starts. Exit and relaunch with the channel flag.

The MCP server connects and its tools work, so why don't messages arrive?
That is the exact symptom of Channels being off at the org level. The server still connects, but channel messages are dropped. Check the startup warning, then ask your Owner to check Organization settings → Claude Code → Channels.

I'm an Admin but the toggle doesn't change.
Enabling Channels requires the Owner role.

Does enabling Channels connect everyone to AgentRQ, Telegram or Discord automatically?
No. It only allows Channels. Each developer still sets up a channel and names it with --channels or --dangerously-load-development-channels when they start a session.

Are Channels available on Bedrock, Google Cloud or Microsoft Foundry?
No. They need Anthropic authentication, either a claude.ai login or a Console API key.

Is this stable?
Channels are still a research preview. Anthropic says the flag syntax and the protocol may change, so check the official Channels docs before you script it.

Has your team turned Channels on yet? What's the first thing you'd hand to an agent you can reach from your phone? Tell us in the comments.

Codex CLI YOLO mode: two knobs, one flag, and why --yolo also kills the sandbox

Tony — Sat, 10 Oct 2026 15:30:53 +0000

TL;DR

codex --yolo is a short alias of --dangerously-bypass-approvals-and-sandbox. It sets approvals to never and the sandbox to danger-full-access.
That second part is unusual. Claude Code's and Gemini CLI's YOLO modes skip prompts but leave sandboxing alone. Codex's removes both.
The two knobs are orthogonal: -a never -s workspace-write gives you "never ask, but stay fenced", which is what most people actually want.
The sandbox is real OS isolation: Seatbelt (sandbox-exec) on macOS, bubblewrap + seccomp on Linux/WSL2, a native sandbox on Windows, and nothing on WSL1.
codex exec never asks for approval, so in CI the sandbox is the only knob that matters.

Every flag below was checked against openai/codex at commit 72c9595 (release 0.161.0), @agentclientprotocol/codex-acp 2.1.1 and OpenAI's Codex docs on October 7, 2026.

What are the two knobs?

Codex models safety as two independent dimensions:

Knob	Config key	CLI flag	Values
When to ask you	`approval_policy`	`-a` / `--ask-for-approval`	`on-request` (default), `never`, or a `granular` table
What a command can reach	`sandbox_mode`	`-s` / `--sandbox`	`read-only`, `workspace-write`, `danger-full-access`

on-request means the model may stop and ask whenever it wants to do something the sandbox would block. The sandbox then decides, at the OS level, which files are writable and whether there's network.

Because the knobs are independent, you get a 2×3 grid of behaviours. The interesting cells:

codex -a never -s danger-full-access   # == codex --yolo
codex -a never -s workspace-write      # never asks, still fenced
codex -a on-request -s danger-full-access  # no fence, may still ask (rarely does)

The middle one has a lovely failure mode: when a command needs more than the sandbox allows, it simply fails, and the error goes back to the model to work around. No human in the loop, but no escape either.

On the CLI, -a only accepts on-request and never. Combining flags that both set a knob is rejected: --yolo can't be combined with -a, and --approve-for-me can't be combined with -a, -s or --yolo.

Why does Codex's YOLO also drop the sandbox?

Because the flag's own help text says it's meant for environments that are already sandboxed from the outside (it calls itself "EXTREMELY DANGEROUS"). The design assumption is: if you're telling Codex "never ask", you're probably in a container, VM or CI runner where an inner sandbox is just friction. That assumption is great in CI and terrible on your laptop.

Here's what danger-full-access actually means. Not "the project". Everything your user account can reach:

Every file you can read or write: ~/.ssh, ~/.aws, ~/.config/gcloud, browser profiles, other repos, dotfiles.
Unrestricted network: download-and-run, call APIs with any token it finds, exfiltrate anything.
Your git identity: .git is no longer protected, so history rewrites and git push --force go out as you.
Every exported env var in the shell that started Codex.

Now add prompt injection. A malicious instruction in a README, an issue, or a fetched web page can steer the model, and with YOLO on nothing pauses to ask you.

How is the sandbox actually built?

Platform	Mechanism	Notes
macOS	Seatbelt via `sandbox-exec`	Built into the OS, nothing to install
Linux	bubblewrap + a seccomp network filter	Uses `bwrap` from `PATH` or a bundled copy. The old Landlock backend is legacy and refused for filesystem-restricted policies
WSL2	Same as Linux
WSL1	None	WSL1 can't create the user namespaces bubblewrap needs, so Codex refuses sandboxed commands
Native Windows	Codex's own sandbox	Unelevated and elevated variants; `/setup-default-sandbox` sets up the elevated one

The Linux one is the gotcha. bubblewrap needs unprivileged user namespaces. Inside an unprivileged container they're often unavailable, you get a startup warning, and the sandbox can't start. That's the one situation where running --yolo inside a container is the normal setup rather than a shortcut: the container is the sandbox.

Even in workspace-write, Codex keeps .git, .codex and .agents read-only, so it can't rewrite history or its own config without asking. That's a neat detail: the agent's own control plane is outside its write fence.

How do I get most of YOLO without dropping the fence?

Most YOLO cravings come from two workspace-write limits: no network, and no writes outside the project. Open them individually:

sandbox_mode = "workspace-write"
approval_policy = "never"

[sandbox_workspace_write]
network_access = true
writable_roots = ["/Users/me/.cache/pip"]

network_access makes npm install/pip install work. writable_roots (or --add-dir <DIR> per run) adds folders. exclude_tmpdir_env_var and exclude_slash_tmp remove $TMPDIR and /tmp from the writable set if you want it tighter.

How does config precedence work, and where does project trust fit?

Codex reads ~/.codex/config.toml (or $CODEX_HOME/config.toml). The YOLO default is just:

approval_policy = "never"
sandbox_mode = "danger-full-access"

A few precedence rules worth knowing:

-c key=value overrides any key for one run.
Permission profiles: default_permissions = ":danger-full-access" (also :workspace, :read-only) is the newer form, and wins over sandbox_mode when set.
Profiles: codex -p yolo layers ~/.codex/yolo.config.toml on top of your normal config. Keeping YOLO in a profile means it's opt-in per launch. (Old [profiles.yolo] tables still load, but -p now means the separate file.)
Managed requirements.toml: an admin can forbid never or danger-full-access, and Codex falls back to the allowed default.
Retired value: approval_policy = "untrusted" is now a hard error at startup. on-failure is still accepted as another name for on-request.

Project trust is how Codex handles the "random cloned repo" problem. The first time you open a folder, Codex asks whether you trust it and records trust_level = "trusted" under [projects."/path"] in your config. A trusted, version-controlled project starts in workspace-write + on-request; anything untrusted or not under version control starts read-only. Trust only sets the default: an explicit --yolo or config key still wins. The point is that the decision lives in your home directory, not in the repo.

How does the in-session switch work?

/permissions opens a picker with three presets:

Preset	Approvals	Sandbox
Read Only	on-request	`read-only`
Default	on-request	`workspace-write`
Full Access	never	`danger-full-access` (the YOLO preset)

With the Auto-review experiment on, there's also an Auto-review mode that routes approvals to an automatic reviewer (the CLI equivalent is --approve-for-me, hidden alias --not-so-yolo, which pairs that reviewer with workspace-write). /approvals is gone; /approve only retries one action the reviewer rejected. There's no keyboard shortcut to Full Access, which is deliberate friction.

Gotcha: config is read at session start. Edit config.toml mid-session and nothing changes until you restart or use /permissions.

What changes in CI with codex exec?

codex exec runs one task non-interactively. There's nobody to ask, so it never asks and has no -a flag. The sandbox is the only knob, and it defaults to read-only:

codex exec "summarize the open TODOs"                        # read-only
codex exec --sandbox workspace-write "fix the failing tests"
codex exec --yolo "run the full release script"              # no sandbox

exec refuses to run outside a git repo unless you pass --skip-git-repo-check (or --yolo, which skips it too). --json streams JSON Lines events; -o <file> writes the final message. Use CODEX_API_KEY scoped to that one step, not job-wide, if the workflow checks out untrusted code.

On GitHub, openai/codex-action@v1 keeps the key behind a proxy, drops sudo by default (safety-strategy: drop-sudo), and takes permission-profile: ":workspace". A hosted runner is exactly the "outer sandbox" --yolo assumes, but the workspace profile is usually enough.

Two more things YOLO does not skip: hooks still need to be trusted once (--dangerously-bypass-hook-trust exists for automation that vets them), and --full-auto is simply gone (use -s workspace-write).

How does YOLO map over ACP?

Codex doesn't speak the Agent Client Protocol natively. @agentclientprotocol/codex-acp is a stdio adapter that starts the Codex App Server and translates both ways. Over ACP there are no flags, just four session modes:

ACP mode	Approvals	Sandbox	CLI equivalent
`read-only`	asks you	read-only	`-s read-only`
`workspace-write`	asks you	workspace-write	`/permissions` Default
`agent` (default)	automatic reviewer	workspace-write	`--approve-for-me`
`agent-full-access`	never	danger-full-access	`--yolo`

Note the default is agent, so Codex over ACP doesn't ask you about most things even before YOLO. INITIAL_AGENT_MODE=agent-full-access starts it in YOLO; CODEX_CONFIG merges a JSON object into session config.

How do I turn on YOLO per task or per workspace with AgentRQ?

Every Codex switch above is session-scoped. If you want YOLO for one job and approvals for everything else, move the decision out of Codex and into a task.

1. Connect Codex through the ACP Gateway (Codex CLI ACP setup guide):

npx @agentrq/acp-gateway@latest --login --agent codex-acp   # once
npx @agentrq/acp-gateway@latest --agent codex-acp

The gateway moves each new session out of any self-approving mode (Auto review, Full access) and into read-only, so every edit and command comes to you as a permission request in the AgentRQ task, on the web, your phone or Slack. You answer:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list.
Deny: Codex gets the rejection; you can reply with what to do instead.

If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing (--permission-timeout changes it).

2a. Per task. Flip the YOLO toggle on a task, or set it at creation. Every permission request in that task is auto-approved; every other task still asks. Scheduled tasks, event triggers and workflow steps have the same switch. The per-task flag persists across agent disconnects and reconnects.

2b. Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

The trade-off. Workspace-wide is AgentRQ's version of putting approval_policy = "never" in your global config: zero friction, but it outlives the job you trusted. Per-task YOLO scopes it to one unit of work. Crucially, YOLO in AgentRQ only removes the questions: Codex keeps the sandbox of the mode it's in, so it never turns into danger-full-access. Concrete example: task A ("upgrade test deps and fix what breaks", YOLO on) runs to the end unattended; task B ("clean up the staging deploy script", YOLO off) pings your phone for ./deploy.sh --dry-run (Allow Once) and later git push --force origin staging (Deny, "open a PR instead"). Same Codex, same gateway. Start YOLO tasks from a clean git tree and check the tool call history afterwards. More in the YOLO mode feature page.

FAQ

Is --yolo the same as --dangerously-bypass-approvals-and-sandbox? Yes, identical.

How do I get no prompts but keep the sandbox? codex -a never -s workspace-write.

Why "unexpected argument '--yolo'"? Your Codex predates the alias. npm install -g @openai/codex@latest or brew upgrade --cask codex.

Why does Codex still ask in YOLO? Config changed mid-session, only one of the two keys is set, an admin requirements.toml forbids it, a hook awaits trust, or you're on ACP where the client picks the mode.

Does Codex sandbox work in WSL1? No. Use WSL2.

Is --full-auto YOLO? It never was, and it's removed. Use --sandbox workspace-write.

Comparing agents? Here's YOLO mode in every coding agent, side by side.

Where do you land: --yolo only inside containers, or -a never -s workspace-write with network_access = true everywhere? And has anyone hit the bubblewrap user-namespace wall in their CI? Tell me in the comments.

Originally published on AgentRQ.

Claude Code YOLO mode: what --dangerously-skip-permissions really turns off (and what it doesn't)

Tony — Fri, 09 Oct 2026 15:35:38 +0000

TL;DR

Claude Code's YOLO mode is officially called bypass permissions: claude --dangerously-skip-permissions, which is exactly claude --permission-mode bypassPermissions.
It removes the permission prompts. It does not touch the Bash sandbox, which is a separate, OS-enforced layer (Seatbelt on macOS, bubblewrap + socat on Linux/WSL2).
deny rules, explicit ask rules and the critical-path rm guard still fire in bypass mode.
A repo's own .claude/settings.json cannot switch YOLO on. Only user settings, managed settings or --settings can.
For most people, auto mode (a classifier reviews each action) is the better "YOLO, but not stupid".

Everything here was checked against Anthropic's docs at code.claude.com and claude --help from Claude Code 2.1.292 on October 7, 2026.

Why does "skip permissions" not mean "no guardrails"?

The first thing to internalize is that Claude Code has two independent safety layers, and they're enforced in completely different places:

Layer	Enforced by	What it gates	Does YOLO remove it?
Permission prompts	Claude Code itself, before a tool call runs	Every tool call: Bash, Edit, Write, MCP tools…	Yes
Bash sandbox	The operating system, while a command runs	Filesystem writes and network egress of shell commands and their children	No

The permission layer is a policy check in the agent's process: "is this tool call allowed, denied, or do I ask the human?" Bypass mode short-circuits the "ask" branch to "allow". Allow rules become irrelevant, because everything is allowed anyway.

The sandbox is a different beast. When it's on, Claude Code wraps each shell command in an OS-level boundary built on Anthropic's open source @anthropic-ai/sandbox-runtime:

macOS: the built-in Seatbelt framework. Nothing to install.
Linux and WSL2: bubblewrap for filesystem isolation and socat to relay network traffic through the sandbox proxy (plus a seccomp filter; /sandbox shows a Dependencies tab if any piece is missing).
Native Windows: no sandbox. Use WSL2.

By default a sandboxed command can write only to the working directory, a per-user temp dir and directories you've added. Network has no direct route out: everything goes through a local proxy that checks each host against an allowlist that starts empty. That's why something like curl --noproxy '*' just fails to resolve: there's no route around the proxy.

So YOLO answers "should I ask?" and the sandbox answers "what can this process physically reach?". You can (and should) run them together.

What survives bypass mode?

Even with every prompt gone, these still apply:

deny rules and explicit ask rules in your permission config.
The guard against rm on critical paths.
Questions Claude asks you directly (it's still allowed to stop and ask).
The sandbox, if you turned it on with /sandbox or "sandbox": {"enabled": true}.

There's one sharp edge in that last point. When a command fails inside the sandbox (say, a tool that's incompatible with it, or a blocked host), Claude can retry it with a dangerouslyDisableSandbox parameter. In bypassPermissions mode, that unsandboxed retry runs without a prompt. Two ways to close the hatch:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

With that set, Claude Code ignores dangerouslyDisableSandbox entirely (the /sandbox Overrides tab calls this Strict sandbox mode). Alternatively, add an ask rule for Bash(dangerouslyDisableSandbox:true); per the docs it prompts even in bypass mode and beats a matching allow rule.

Also worth knowing: the sandbox covers shell commands only. Read/Edit/Write/WebFetch, hooks, local MCP servers and your status line command run outside it, governed only by permission rules. In bypass mode that means they're governed by… your deny rules. If you want one boundary around everything, run the whole claude process in a container or VM.

How do you actually turn it on?

Where	Full YOLO	Halfway
CLI	`claude --dangerously-skip-permissions`	`claude --permission-mode auto` or `acceptEdits`
settings.json	`"defaultMode": "bypassPermissions"`	`"defaultMode": "acceptEdits"`
In a session	Shift+Tab, if allowed at launch	Shift+Tab
VS Code	`claudeCode.allowDangerouslySkipPermissions`	mode selector
Rules	—	`"allow": ["Bash(npm test)"]`

The flag:

claude --dangerously-skip-permissions
# identical to:
claude --permission-mode bypassPermissions

--permission-mode takes manual (the default, spelled default in config files), acceptEdits, auto, plan, dontAsk and bypassPermissions. The first interactive run shows a warning you have to accept.

As a persistent default, in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

Why can't a cloned repo flip YOLO on for you?

This is my favourite design decision in the whole permission system. defaultMode: "bypassPermissions" is honoured in user settings, managed settings and a file passed with --settings. It is ignored in a project's own .claude/settings.json and .claude/settings.local.json: Claude Code just starts in the default mode.

Think about the threat model. Project settings ship with the repo. If they could set bypass mode, then git clone evil/repo && cd repo && claude would hand an attacker an agent that runs anything without asking, and the attacker's README or issue text is right there to prompt-inject it. The rule is simple: only scopes you control can lower your guard. The same idea shows up elsewhere in the sandbox docs, where credential-masking settings are honoured only from user/managed/--settings scopes and ignored in a repo's settings.

Cloud sessions ignore bypassPermissions from settings files too, and admins can kill the mode org-wide:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Why won't --dangerously-skip-permissions run as root?

On Linux and macOS, Claude Code refuses to start in bypass mode as root or under sudo, unless it detects it's already inside a sandbox. That's the "no prompts and unlimited privilege" combination it won't sign off on. If you hit this in a container, it's the container detection that matters; on a bare host, the fix is "don't be root", not "find a workaround".

Why isn't bypass in my Shift+Tab cycle?

Shift+Tab cycles auto → default → acceptEdits → plan, then any optional modes. Bypass is only part of the cycle if the session was launched with permission to use it. To have it available without starting in it:

claude --allow-dangerously-skip-permissions

It's a nice two-step arm-then-fire design: the capability is granted at process start (a deliberate act), and only then can a keystroke reach it. A stray Shift+Tab in a normal session can never land you in YOLO.

In VS Code, claudeCode.allowDangerouslySkipPermissions plays the same "arm" role: it adds Bypass permissions to the mode selector. claudeCode.initialPermissionMode sets what new conversations start in (default, acceptEdits, plan, bypassPermissions).

Is auto mode just YOLO with extra steps?

No, and it's what I'd reach for first. In auto mode a separate classifier model reviews each action and only stops you for the risky ones. Since 2.1.283 it's the default starting mode in the terminal and VS Code on supported models.

The other halfway options compose nicely:

acceptEdits: file edits go through, shell commands still ask.
Allow rules: "Bash(npm test)", "Bash(git *)", "Read" in permissions.allow, or --allowedTools.
Sandbox auto-allow: with the sandbox on, sandboxed Bash commands can run without prompts because the OS, not you, limits what they can reach. Deny rules, critical-path rm and content-scoped ask rules like Bash(git push *) still prompt.

That last combo is, for me, the sweet spot: zero prompts for npm test and friends, but a kernel-enforced fence around writes and egress.

How do I turn on YOLO per task or per workspace with AgentRQ?

Everything above is session-scoped: you decide once, at launch or with Shift+Tab, and that decision covers every tool call until you exit. If you run Claude Code unattended (scheduled jobs, long refactors while you're away), you usually want something finer: YOLO for this job, prompts for everything else. That's the gap AgentRQ fills by moving the approval decision out of the terminal and into a task.

1. Connect Claude Code to a workspace. Follow the Claude Code setup guide, which adds the workspace as an MCP server and a notification channel. Alternatively, run it through the ACP Gateway with --agent claude-acp.

2. Start Claude Code without bypass. Use the default mode or acceptEdits, for example:

claude --permission-mode acceptEdits

Avoid auto mode here, otherwise the classifier answers the permission requests before they ever reach you. Each request now shows up in the AgentRQ task (web, phone or Slack) with the command or edit it's about, and you answer one of:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
Deny: Claude Code gets a rejection and carries on with another approach.

3a. YOLO for one task. Flip the YOLO toggle on a task, or set it when you create the task. Every permission request in that task is approved automatically and Claude Code never waits, while every other task in the workspace still asks. The flag is per task and persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so a nightly job can run in YOLO while your interactive work stays supervised.

Per task vs. workspace-wide, the trade-off: the workspace switch is the AgentRQ equivalent of putting bypassPermissions in your user settings: convenient, but it outlives the job you actually trusted, and it covers work you haven't seen yet. Per-task YOLO scopes the blast radius to one unit of work and expires with it. My rule: leave Execute All off, use per-task YOLO for jobs you'd happily git reset, and lean on Always Allow for boring tools (prune that list now and then). Either way, Claude Code's own layers still apply underneath:

Keep /sandbox on, ideally with allowUnsandboxedCommands: false. AgentRQ removes the questions; the sandbox still limits what an approved command can touch.
Start every YOLO task from a clean git tree, so any change is one git reset away.
Read the tool call history afterwards; it lists every call, including the auto-approved ones.

FAQ

Is --dangerously-skip-permissions the same as --permission-mode bypassPermissions? Yes, exactly the same.

Does YOLO mode turn off the sandbox? No. It only skips prompts. But unsandboxed retries run without asking in bypass mode unless you set allowUnsandboxedCommands: false.

Can I put bypass mode in my repo's .claude/settings.json? You can write it, but Claude Code ignores it there. Use ~/.claude/settings.json, managed settings or --settings.

Why does it refuse to start as root? Bypass mode is blocked as root/sudo on Linux and macOS unless Claude Code detects it's already sandboxed.

Why is bypass missing from Shift+Tab? Start the session with --dangerously-skip-permissions or --allow-dangerously-skip-permissions, or set bypass in user settings.

Does the sandbox cover MCP servers and hooks? No. They run with your full access; only shell commands are sandboxed.

Can I approve Claude Code permissions from my phone? Yes. Connect it to an AgentRQ workspace and answer Allow Once, Always Allow or Deny in the task.

If you're comparing agents, here's how YOLO mode works in every coding agent, side by side.

So, what's your setup: full bypass inside a container, auto mode on the host, or sandbox auto-allow with a strict no-retry policy? And has the unsandboxed retry ever surprised you? Tell me in the comments.

Originally published on AgentRQ.

There is no agy --yolo. How YOLO mode actually works in Antigravity (IDE and CLI)

Tony — Thu, 08 Oct 2026 15:37:53 +0000

TL;DR

agy --yolo is not a flag. The CLI's YOLO is agy --dangerously-skip-permissions, or "toolPermission": "always-proceed" in ~/.gemini/antigravity-cli/settings.json.
In the Antigravity IDE, YOLO is the Turbo permission preset.
The two are not equivalent. Turbo turns off approvals and the sandbox, and opens the whole filesystem. The CLI flag turns off approvals only, and leaves the terminal sandbox however it was, which by default means off.
The sane middle ground is the IDE's Default preset, or proceed-in-sandbox in the CLI with the sandbox actually enabled.

Checked against Google's Antigravity docs (antigravity.google/docs) on October 7, 2026. Antigravity is closed source and Google doesn't publish the CLI's full flag list, so everything here comes from the documentation, not the code.

Why are people typing `agy --yolo` in the first place?

Migration muscle memory. On June 18, 2026, Google moved free, Google AI Pro and Ultra users from Gemini CLI to the Antigravity CLI. Gemini CLI had --yolo (now deprecated in favour of --approval-mode=yolo). agy didn't carry it over. Instead, it borrowed Claude Code's spelling:

agy --dangerously-skip-permissions

The naming is a design statement in itself. "yolo" sounds like a fun mode. "dangerously skip permissions" says what you're giving up. Google's CLI guide lists it with --sandbox as launch flags that override your saved settings for that one session, and the settings panel shows when a value came from a flag rather than the file.

What are the two layers YOLO can touch?

Like most serious agents, Antigravity separates two questions:

Approval: does a human confirm this tool call before it runs?
Containment: once it runs, what can it reach?

Where the IDE and CLI differ is in how their "YOLO" maps onto those layers:

	Approvals	Terminal sandbox	Filesystem	MCP / web tools
IDE Turbo	Off	Off	Whole filesystem	Allowed
CLI `--dangerously-skip-permissions`	Off	Unchanged (`--sandbox` / `enableTerminalSandbox`, default off)	Unchanged	Allowed (no prompts)

So "YOLO in the CLI" leaves you exactly as sandboxed as you were before. On a stock install, that's not at all. Turbo is the more honest of the two: it's labelled as the everything-off preset.

How does the CLI's toolPermission work?

The CLI keeps settings in ~/.gemini/antigravity-cli/settings.json, and it only writes the keys you change. The one that matters is toolPermission, which takes four values. Ordered from most to least paranoid:

Value	Behaviour
`strict`	Asks before every tool that isn't a read
`request-review` (default)	Asks before writes, shell commands and web tools
`proceed-in-sandbox`	Runs terminal commands without asking as long as they stay in the sandbox, asks otherwise
`always-proceed`	Never asks. This is YOLO

proceed-in-sandbox is the interesting design. Approval depends on containment, so the prompt only appears when the command wants out. The catch is that it's only meaningful if the sandbox is on:

{
  "toolPermission": "proceed-in-sandbox",
  "enableTerminalSandbox": true
}

In-session, /permissions opens the permissions manager (mode and rules for the running session), and /config or /settings opens the full editor. When a subagent is waiting on an action, Ctrl+K approves just that one action.

Can I get something finer than a global mode?

Yes, with rules. A permissions block takes allow, ask and deny lists:

{
  "permissions": {
    "allow": ["command(git)", "command(npm test)", "write_file(src/)"],
    "deny": ["command(rm)"]
  }
}

Matchers cover commands (including command(regex:...)), file writes, URLs and MCP tools (mcp(server/tool)). Precedence is the conservative one: deny beats ask, ask beats allow. So a broad allow can never swallow a specific deny, and that's what lets you safely allow command(git) while still denying something narrower.

What do the IDE presets actually configure?

On macOS and Linux: Settings → General → Permission Settings. A project can override the preset or choose Inherit General.

Preset	Sandbox	Terminal commands	Files	MCP and web
Default	On	Free inside the sandbox, ask outside	Workspace + temp	Ask
Request Review	Off	Always ask	Workspace only	Ask
Turbo	Off	Run without asking	Whole filesystem	Allowed

Look at the shape of Default. It isn't "ask about everything". It's the IDE version of proceed-in-sandbox: the agent runs freely while it's contained, and stops when it wants to leave. For most work that's the better trade than Turbo. You keep the speed, and the blast radius stays at "workspace + temp".

Request Review is the odd one out. It turns the sandbox off, but makes up for it by asking about every command and limiting files to the workspace. That's human review instead of OS containment.

Two more IDE knobs:

Artifact review policy (asks-for-review, agent-decides, always-proceed) decides whether the agent waits for you to review its plans and other artifacts. It's YOLO for planning, separate from YOLO for tools.
Strict mode is the anti-Turbo. It sends terminal commands, browser JavaScript and artifacts to review, and turns the sandbox on with no network.

Windows still uses the older model. Set Terminal Command Auto Execution to Always Proceed (it still respects your deny list) and the outside-of-folder file access policy to Always Allow. Sandbox mode is a separate toggle there.

Is there an "Antigravity 2.0 YOLO mode"?

Forum posts mention "Antigravity 2.0", but we found no official 2.0 page that changes the permission model. Today's documented options are Turbo in the IDE and --dangerously-skip-permissions / always-proceed in agy. If that changes, the doc pages above are where it'll show up first.

How do I turn on YOLO per task or per workspace with AgentRQ?

Both native switches cover a whole session (or a whole IDE preset). AgentRQ moves the decision to the task, and lets you answer prompts away from the terminal.

1. Connect Antigravity through the ACP Gateway (Antigravity setup guide). Its registry build publishes no checksum, so the first run needs --allow-unverified-agent:

npx @agentrq/acp-gateway@latest --agent antigravity-acp --allow-unverified-agent

Start it without --dangerously-skip-permissions or always-proceed. The gateway also moves each new session out of any self-approving mode and into one where the agent asks a person.

2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, your phone or Slack, with the command or edit it wants to run. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes the limit.

3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every request in that task is auto-approved, and every other task still asks. The flag lives on the task, so it survives agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.

The trade-off. Per-task YOLO is scoped trust: it ends with the job you vetted, so a nightly scheduled run can be YOLO while your interactive tasks stay supervised. Workspace-wide YOLO is less friction, but every future task inherits it. With Antigravity in particular, remember the layering above. AgentRQ's YOLO only answers the approval question, so set "enableTerminalSandbox": true and auto-approved commands still run inside the sandbox. Add a clean git tree before each YOLO task and a look at the tool call history afterwards. More: AgentRQ YOLO mode.

FAQ

Does agy --yolo exist? No. Use agy --dangerously-skip-permissions, or "toolPermission": "always-proceed".

What's the difference between Turbo and the agy flag? Turbo also turns off the sandbox and opens the whole filesystem. The CLI flag only skips approvals.

Is the agy terminal sandbox on by default? No. Enable it with --sandbox or "enableTerminalSandbox": true.

What's the safest "fast" setting? The IDE's Default preset, or proceed-in-sandbox with the sandbox on in the CLI: no prompts while contained, a prompt when the agent wants out.

Do deny rules still work with always-proceed? The docs say Windows' Always Proceed respects the deny list. For rules in general, deny beats ask beats allow.

How do I approve Antigravity commands from my phone? Connect it to AgentRQ through the ACP Gateway. Permission requests show up in the task.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Question for the comments: is "approve automatically only while sandboxed" (Default / proceed-in-sandbox) the pattern every agent should copy, or does it just move the trust problem into the sandbox config? 👇

Originally published on AgentRQ.

Use Claude right inside your Chrome and let it play with WebMCP tools

Mustafa Turan — Fri, 02 Oct 2026 03:00:01 +0000

TL;DR: WebMCP lets a website offer tools to AI agents, but only an agent inside that same tab can call them. We built a Chrome extension that removes that limit. Share a site with a workspace, and Claude Code (or Codex, or any MCP agent) can call the site's tools from your laptop or from a server in another building. The call runs in your signed-in tab, and anything that writes waits for your approval. The same popup also shows the live Claude Code terminal of every agent on every machine you've connected. Below are the problems we hit building both, and how we solved them.

What problem does WebMCP leave open?

WebMCP is a young browser standard. A page registers tools with document.modelContext, such as "search the docs" or "create an issue", each with a name, a description and a JSON Schema for its input. An agent can call them without scraping the page or clicking through it.

There's a catch: the tools live in the page's JavaScript. Only an agent running in that browser, in that tab, can reach them. Your Claude Code session in a terminal can't. Neither can the agent on your build box, or the one a cron job wakes up at 3am.

Those are the agents doing most of the work. So we asked: what would it take to give a page's tools to an agent that isn't anywhere near the browser?

Here's where we ended up:

 Claude Code / Codex / any MCP agent  (laptop, build box, cloud VM)
              │  MCP: listSiteTools · getSiteToolDefinition · callSiteTool
              ▼
         AgentRQ server ── approval in the task, if the tool writes
              │  WebSocket, opened by the browser
              ▼
   Extension service worker ── picks the right tab
              │  chrome.runtime messages
              ▼
   Bridge (isolated world) ⇄ Observer (page's world) ── tool.execute()

Part 1: The WebMCP bridge

Challenge 1: How do you see a page's tools without becoming a tool provider?

The obvious approach is to inject a modelContext and see what the page puts in it. We didn't, because then the extension would decide which pages get WebMCP and how it behaves. A page that feature-detects WebMCP would detect us instead of Chrome.

Instead, a small observer script runs in the page's own JavaScript world at document_start, in the top frame only. It wraps the browser's native registerTool so that it still calls through to Chrome, and it records what was registered. If the browser has no modelContext, the observer does nothing. It never adds one.

Three edge cases turned out to matter:

Tools can be withdrawn. registerTool takes an AbortSignal. When a page aborts a tool, any calls still running on it fail with a clear error instead of hanging.
Re-registration wins. If a page registers the same name twice, the newer one replaces the older one, and an abort on the stale one doesn't remove the new one.
Descriptors must survive JSON. A tool whose description or schema can't be serialized can never be described to a remote agent, so we drop it at the door.

Challenge 2: How do you talk to page code without the page listening in?

Content scripts come in two worlds. The main world shares JavaScript with the page, so it can wrap registerTool, but it can't use extension APIs. The isolated world can use chrome.runtime, but it can't see the page's objects. So the design needs two scripts, the observer and a bridge, and they have to talk over the DOM, which the page can also use.

A fixed event name like agentrq-call would let any page listen to every call or forge results. Here's what we did instead:

The bridge (isolated world) generates a random UUID and drops it on <html> as a data attribute.
The observer (main world) runs next. It reads the nonce and deletes the attribute before any page script runs.
Every message travels as a CustomEvent whose event type is the nonce. The page doesn't know the event name, so it can't subscribe and can't forge.
The observer saves dispatchEvent, CustomEvent and JSON at startup, so a page script that patches them later can't intercept anything.

Gotcha: this depends on the bridge running before the observer. Chrome runs document_start scripts in order of their registration IDs, not the order you register them in. The bridge's ID has to sort first alphabetically. We learned that the hard way.

Challenge 3: How does a server reach a browser behind NAT?

It can't, so the browser dials out. The extension's Manifest V3 service worker opens a WebSocket to the AgentRQ server. That brought three MV3 problems:

A WebSocket from a service worker carries no cookies. The worker first asks for a one-minute ticket using your normal sign-in cookie (refreshing the short-lived access token once if needed), then connects with that ticket.
Chrome kills idle service workers. An open socket keeps the worker alive only while traffic flows, and pings from the server don't count. So the worker sends its own ping every 20 seconds.
No socket unless it's needed. The socket is open only while at least one site is shared. When it drops, it reconnects with backoff from 1s up to 30s.

Challenge 4: Which tab runs the call?

You might have three tabs of the same site open, or none. The worker tracks every tab that has announced tools and sends each call to the most recently used tab of that origin that offers that tool. If you've closed them all, it reopens the site in a background tab and waits for the page to register the tool again.

Navigation was the messiest part:

A page unloading mid-call fails only the calls sent to that document. After a cross-site navigation, the new page may have announced its tools before the old page's unload event arrives, so we track calls by document, not by tab.
The back/forward cache restores a page without re-running its scripts, so the observer never announces again. The bridge keeps the page's last tool list and sends it again on a persisted pageshow.
A navigate tool (one that moves the page somewhere) sends its result before the page unloads. Results and "page gone" go through the same channel in order, so the result arrives first instead of being reported as a failure.

Challenge 5: How do you keep remote tools from eating the agent's context window?

If you send every schema of every tool on every shared site with each listing, the agent pays for it in tokens on every call. So the MCP surface has three steps:

listSiteTools returns only names and descriptions, plus whether each site is online.
getSiteToolDefinition returns one tool's full input schema when the agent actually wants to use it.
callSiteTool runs it.

The server validates arguments against the page's own JSON Schema before anything reaches your browser, so a malformed call fails fast with a message the agent can fix. Calls have a 60-second deadline and results are capped at 256 KiB.

Challenge 6: How do you let a remote agent act as you without handing it your credentials?

This is the part we think matters most. The call runs in your signed-in Chrome, with your session on that site. The agent never sees a password, a cookie or an API token. To the site, it's just you, in your tab, using a tool the site chose to offer.

That makes approval essential:

Tools the site annotates as read-only (a search, say) just run.
Anything else asks first. The request appears in the task the agent is working on, showing the tool and the exact arguments as pretty-printed JSON. You choose Allow once, Always allow <tool> on this site, or Deny. "Always allow" is remembered per site and per tool.
The agent has to pass the taskId it's working on, so every write is tied to a piece of work you can see.
Only a human can share a site, from the popup, one site at a time. An agent can't add one.
Detection is off by default. Until you turn it on, the extension doesn't even look. Once it's on, nothing leaves the browser until you click Share.

We also put effort into the failure messages, because the agent is the one reading them. If Chrome is closed, the agent doesn't get a vague "connection refused". It's told the human's Chrome isn't connected and to ask them to open it. If a site doesn't have the tool it asked for, the error lists the tools it does have.

Part 2: Claude Code's terminal, inside the extension

Click the toolbar icon (or press Alt+Shift+A), open an agent, and you get its real, live terminal, not a log or a summary. You can watch it, scroll back, or type into it and take over. It works the same for the agent on your laptop, the one on the box under your desk and the one on a cloud VM, without SSH or a tmux attach.

Challenge 7: Why not just bundle the web app into the extension?

Code bundled into an extension runs on the extension's own chrome-extension:// origin, and your sign-in cookie never goes there. You'd be signed out no matter what. So the popup frames the server's own web app instead. Everything the web app can do works in the popup, with the same session as your tabs.

Two browser limits shaped the rest:

A framed page gets its cookie only if the extension has host permission for that site. That's why the extension asks to read app.agentrq.com (or your self-hosted server, which is asked for when you save it and given back when you switch away).
Google and GitHub refuse to show sign-in inside a frame. A signed-out popup opens sign-in in a tab, and once you're signed in there, the popup is too.

Chrome caps popups at 800×600 and closes them when you click away, so the popup is phone-sized (440×600). Full size (Alt+Shift+F) opens the same app in a tab.

Challenge 8: How do you replay a terminal that redraws itself 100 times a second?

The terminal comes from a small daemon on each connected machine. It runs the agent in a pseudo-terminal (ConPTY on Windows, openpty everywhere else) and dials out to the server. There are no inbound ports to open.

The first instinct is to keep a ring buffer of output and replay it when someone opens the terminal. That fails with Claude Code, because a spinner or progress bar isn't much output. It's one line rewritten constantly. 256 KiB of ring buffer becomes 256 KiB of the same line, and the history you cared about is gone. Replaying it in a fresh terminal shows a thousand frames of how the screen got there instead of what it shows now.

So the daemon keeps its own terminal emulator for each session and feeds it every byte, whether or not anyone is watching. When you open the terminal, it sends a redraw of the current screen, the same thing tmux does when a second client attaches. A progress bar shows up looking like a progress bar.

Challenge 9: How do you handle backpressure without corrupting the stream?

"Drop the oldest bytes" is destructive for a terminal. The stream is stateful: drop an ESC[0m and the colors stay wrong for the rest of the session, and drop half an escape sequence and the emulator parses garbage. So:

Output is coalesced in 25 ms windows, which is about one frame. A spinner redrawing 100 times a second becomes roughly 40 sends with no visible difference.
No byte is ever dropped. If the connection can't keep up, the pending batch is thrown away as a whole and replaced with a redraw of the screen. The viewer misses some in-between frames but always sees a correct screen.

Challenge 10: Why is input never batched?

It's tempting to batch keystrokes the way output is batched. But that would add latency to every keypress, and it would merge a deliberate Esc with the next key into an escape sequence nobody typed. Esc is how you interrupt Claude Code, so that can't happen.

Every keystroke is sent the moment it's typed, as the exact bytes xterm.js produced: 0x1b for Esc, \r for Enter, ESC [ A for the up arrow. There is no list of "special keys". Any such list would be wrong for the next key combination someone needs, while a transparent byte pipe handles all of them.

One rule here is about security. The browser doesn't choose which session it types into. The server decides which session an attached viewer may drive and overwrites whatever session ID arrives. Otherwise, changing a number would let you type into someone else's agent.

That rule came from a bug. The first version took the session ID from the caller and converted it with BigInt, which throws on a base62 string. Every keystroke threw while output kept arriving, so the terminal looked like it was ignoring the keyboard. The unit tests passed numeric IDs and never caught it.

Challenge 11: Why did terminals sometimes go blank?

Claude Code's interface is mostly box drawing. The DOM renderer asks the font for those glyphs, and the font we ship doesn't include them, so we use xterm's WebGL renderer, which draws box characters itself. WebGL has two failure modes:

It fails late. On VMs, GPU-less Chromium and machines with blocked drivers, it fails inside activate(), not in the constructor. So each renderer is tried by actually loading it, and if one throws we move to the next. The last fallback is the plain DOM renderer, because a terminal that renders imperfectly beats one that renders nothing.
It can lose its GPU context at any time, through a driver reset, a laptop switching GPUs, or too many contexts in other tabs. Afterward it never draws again, and a blank terminal looks exactly like an agent that stopped. So we rebuild the renderer once. If the context is lost a second time, we drop to the next renderer and stay there, rather than burning GPU contexts in a loop.

What did we trade away?

Your Chrome has to be open. Calls run in your browser, so a closed laptop means the site is offline. We chose that over storing your credentials on a server. The agent gets a clear "offline" error rather than a hang.
It only works with sites that ship WebMCP. It's an early standard and the list is short. agentrq.com offers three tools and the AgentRQ app exposes its own interface, so there's something to try today.
Approvals add a human in the loop. That's by design for writes, and "Always allow" per tool keeps it from getting in the way.
The popup is small. Chrome sets that limit. Full size is one shortcut away.

FAQ

Which agents can call shared sites? Any agent connected to the workspace over MCP, including Claude Code, Codex and Antigravity. There's nothing to install on the agent's side and no token to paste.

Does the extension read every page I visit? Only with detection on, and even then it only checks whether the top frame registers WebMCP tools. Nothing is sent until you share a site. After that, only that site's tool list, its last address and the results of your agents' calls go to your AgentRQ server.

Can I self-host? Yes. Set your server's address in Options.

Is it open source? Yes. The extension, the daemon and the server are all in the agentrq repository.

Try it

Install AgentRQ for Chrome, turn on detection, open agentrq.com, share it with a workspace, and ask Claude Code to search the docs.

Over to you: if your agents could call any site you're signed into, through tools the site chose to offer and with you approving every write, which site would you hand them first? And if you've built on WebMCP or MV3 service workers, which of these problems did you hit differently? Tell us in the comments.

Originally published on the AgentRQ blog.

Stop Overwriting Your AI Agent's Task Status: Why We Keep an Immutable State History

Mustafa Turan — Wed, 30 Sep 2026 01:33:27 +0000

An agent picks up a task, works on it, marks it completed. You look at it the next morning.

How long did it take? How much of that was the agent working, and how much was it waiting for you to click Allow?

For a long time AgentRQ (an open-source task board and MCP server for Claude Code and other agents) couldn't tell you. A task had one status field, and every change overwrote it. ongoing → blocked → ongoing → completed, and each write erased the one before. The end state was right. Everything in between was gone, and you can't get a duration out of a snapshot.

We fixed that in agentrq/agentrq#756. This post isn't a code walkthrough. It covers the design decisions behind it, because I think they apply to anyone building agent tooling: why the history is immutable, why the states are a fixed enum, why there is exactly one writer, and why the most useful state in the timeline is one the task can never actually be in, and how it all rolls up into a p50 dashboard.

TL;DR

Keep the current status for everything that asks "what is this task now?", and add an immutable, append-only history beside it for "how did it get here?"
Immutability is what makes the numbers trustworthy: nobody, not the agent, not a person, not a bug, can rewrite how long something took.
States are a closed enum that only ever grows at the end, so a row written today means the same thing in five years.
"Waiting on the human" is a derived, history-only state. It never becomes the task's status, so nothing else in the system behaves differently.
The same history rolls up into a stats dashboard: p50, min and max of start to close, worked, blocked and needs input, per workspace and across the account.

Why is overwriting a status the wrong model for agent work?

Because the interesting question about agent work is almost never "is it done?" It's "where did the time go?"

With a human ticket, you can ask the assignee. With an agent, the only record is what the system kept. If the system kept one mutable field, you have a photograph, not a film.

It's the event-sourcing lesson in miniature: the current state is a projection; the transitions are the data. Keep the transitions and you can always work out the state. Keep only the state and the transitions are lost for good.

We didn't go full event sourcing, though. The task's status stays the source of truth for "what is it now", because a lot of the system reads it: the work queue agents pull from, filters, counts, and the MCP tools agents call. We didn't want to touch any of that. The history sits beside it.

What does "immutable history" mean here?

Every status change appends one record: the state the task came from, the state it went to, when, and which agent (and model) made the change. That's it. A record is never edited after it's written, and nothing is ever inserted into the past.

not started   09:00  ─┐ 6m
ongoing       09:06  ─┤ 24m
needs input   09:30  ─┤ 8m
ongoing       09:38  ─┤ 31m
blocked       10:09  ─┤ 38m
ongoing       10:47  ─┤ 19m
completed     11:06  ─┘

A state lasts from its record to the next one. The state the task is in right now lasts until "now", so it keeps counting.

Two honest caveats about "immutable": if you move a task to another workspace, its history moves with it, and if you delete a task, its history goes too. What never changes is the content of a record: which states, and when.

Why does immutability matter so much for agents?

Three reasons, in order of how much they bit us.

1. The numbers have to be trustworthy, or they're useless. The whole point of the timeline is to answer questions like "is this class of work worth handing to an agent?" and "am I the bottleneck?". If records could be edited, every number derived from them would be an opinion. Append-only means the only way to change the story is to add to it.

2. Agents write status too, and they're not always right. An agent might mark a task completed, then get reopened by a person, then complete it again. With an overwritten field, the final completed is all you see. With an immutable history, the false finish is on the record, with its time. That's exactly the kind of thing you want to spot when you're tuning a prompt or a workflow.

3. It makes concurrent writers boring. An agent and a person can move the same task at the same moment: the agent marks it completed while you click Reject. With an append-only log, there's nothing to merge. Both changes are recorded in the order they happened, and each record says where it came from. (We do lock the task while recording, so the second change sees the first one's result as its starting point.)

There's a fourth, quieter benefit: the conversation got cleaner. Every status change used to drop a "Status updated to …" line into the task thread, which buried the messages that mattered. With the history in its own place, those lines are gone.

Why are the states an enum instead of free-form strings?

This looks like a small decision. In an immutable log it's a big one.

A record written today has to mean the same thing forever. Free-form strings drift. Someone writes complete instead of completed, a state gets renamed, a new client sends in_progress. In a mutable column you can fix that with a migration. In an append-only history, "fixing" old records is exactly what you promised never to do. So the set of states is closed: not started, ongoing, blocked, needs input, completed, rejected, and scheduled (cron). Nothing outside that set can be recorded as itself.

The enum only ever grows at the end. Each state is stored as a small number, and new states are appended after the existing ones, never inserted in between or reordered. Reordering would silently change the meaning of every record already written, so it's the one rule that can't be broken. "Needs input" was added exactly this way, as the last value.

There's an explicit "none" state. When a task is created, the first record goes from "none" to its first status. That gives the first segment a start time, and it gives any unrecognised status somewhere safe to land instead of failing the write.

Numbers inside, names outside. Storage uses the compact number, because this history grows with every status change on every task and the workspace stats pages aggregate over it. Everything outside the backend, including the API, the UI and the agents, sees the readable names. The mapping lives in one place.

Why is there only one writer?

Because a history that some code paths forget to write is worse than no history: it looks complete and isn't.

Status changes come from everywhere: the MCP tools agents call, the web app, the CLI, scheduled tasks, events that create tasks in other workspaces. Instead of asking each of those to remember to record a transition, the record is written in one place, the storage layer's task save, and in the same transaction as the status change itself.

That gives two guarantees:

No status change without a record. If recording fails, the status change rolls back. You never see a task that says completed with no trace of how it got there.
No record without a status change. Saving a task for any other reason (a new title, a new description) adds nothing to the history.

Everything above the storage layer sets the status and saves, as it always did. It doesn't know the history exists.

Why is "needs input" a state the task can never be in?

This is the part I'd steal if I were building something similar.

When an agent asks the person something through AgentRQ (a permission request before running a command, or a form question), the task is waiting on the human. That's a different kind of wait from blocked, where the agent hit a wall and said so. They call for opposite fixes, so they deserve separate numbers.

The obvious implementation is a new status. We didn't do that. Agents read and write the status, the work queue hands out tasks based on it, and filters and counters group by it. A new value would change behaviour in all of those places: an agent looking up its ongoing tasks could suddenly miss the one it is in the middle of.

So "needs input" is derived, and it only exists in the history:

While any question in the task's thread is still waiting for an answer, the history records the task as needs input.
When the last one is answered, the history moves it back to whatever its real status is.
The task's own status stays ongoing the whole time.

A few rules made it correct:

It counts open questions, it doesn't toggle. An agent can have two permission requests open at once. Answering the first must not end the wait.
Only real questions count. An agent's plan has to-do items that are "pending" too, but a to-do isn't a question to anyone.
Closed means closed. A question arriving on a completed task doesn't reopen its history.

Because the status never changes, nothing that reads it behaves any differently. Only the timeline and the totals know.

What does it look like?

Under each task's description there's now a task timeline: one dot per state, with the time spent in each on the line between two dots, and the totals above.

Total	Value	Meaning
Worked	1h 14m	All the time the agent was `ongoing`
Blocked	38m	All the time the agent said it couldn't go on
Needs input	8m	All the time a question to the person was open
Start to close	2h	From the first `ongoing` to completed or rejected

Start to close begins at the first ongoing, not at creation, on purpose. A task that sat in the queue overnight shouldn't look like an agent that took twelve hours.

An open task keeps ticking. Here the agent is waiting on a permission prompt, so the last dot is yellow and counting, and there's no start to close yet:

A small consistency detail: the page works out the totals from the same segments it draws, instead of showing the server's numbers next to a bar it animates itself. Otherwise the live counter and the bar would drift apart every second. The server's totals are still in the API for scripts, agents and the stats pages.

On a phone it collapses to one line, the dots and the total:

How does the dashboard tell the story across every task?

One task's timeline tells you what happened to that task. It doesn't tell you whether that was normal. Is two hours usual for this workspace? Did this week go faster than last? Do agents sit blocked longer in one workspace than another?

So the history feeds a second view: a Task Latency panel on each workspace's stats page and on the account stats page. It charts the same four totals, in minutes, over every task closed in the range you pick, with a toggle between P50 (the typical task), Min (the quickest) and Max (the slowest).

Read the cards like a story. This workspace closed 42 tasks in the week. At p50, a task took 108 minutes start to close, of which 66 were work, 19 were blocked and 7 were waiting on a person. (Each line is its own median, so they don't add up exactly, and they aren't meant to.) Hover over Sep 24 and the typical task took 150 minutes, well above the week's figure. That's the day to go and look at.

The account page shows the same panel across every workspace:

Across the account the typical task took 146 minutes and was blocked for 26 of them. The workspace above beats both, so something else is pulling the account figure up, and you know where to look next.

The design decisions behind the numbers:

Why p50 and not the average? Agent task durations have a long tail. One task that sat blocked over a weekend turns a 30-minute average into a 3-hour one, and then the average describes no task you actually ran. The median is the task you'd typically get. Min and max sit next to it on purpose: max finds the one that dragged, and min shows how fast the work goes when nothing gets in the way.

Why an estimated p50? Stats are rolled up per hour, per day and per month, so a three-month chart doesn't re-read every task. But medians don't add up. You can't combine two hours' medians into a day's median. So each rollup keeps a small histogram of durations with fixed, log-spaced buckets: under a minute, 1–2 minutes, 2–5 minutes, and so on through hours and days, up to over 30 days. Histograms merge by adding counts. The p50 is read back out of the merged histogram, interpolated inside the bucket where the median falls, and clamped between the exact min and max, which merge perfectly. It's an estimate, and it's exact when a bucket holds a single task.

The histogram buckets are immutable too. Same lesson as the state enum: counts are stored by position, so the bucket edges can never be changed or reordered. A finer histogram would be a new field, not an edit.

One arithmetic, two views. The task page and the dashboard compute durations with the same function over the same history, so a task's timeline and its contribution to the chart can never disagree.

Every close counts once. When a task closes, its totals are recorded in the same transaction that closes it. If it's reopened and closed again, its totals are recalculated over its whole history, but a period that was already rolled up isn't rewritten. Each close counts once, in the period it happened in.

Zero is data; nothing is a gap. A task that was never blocked counts as 0 minutes blocked, so the blocked line shows how much blocking a typical task really sees, not just the unlucky ones. But a day with no closed tasks is left as a gap in the line, not drawn as zero, so a quiet day never looks like a fast one.

The resolution follows the range. A day or two plots by the hour, up to about three months by the day, and anything longer by the month. All in UTC.

Agents can read it too. The same figures are available to an agent, so you can ask one to watch for a workspace whose blocked time is creeping up, or to report how long its own work took this week.

It shipped as a follow-up, in agentrq/agentrq#758. The full tour is in Task Latency: How Long Your Agents' Tasks Take.

What does it unlock?

"How long did that take?" finally has an answer. Start to close per task is the number you want when you decide whether a class of work is worth handing to an agent at all.

Agent time vs. your time. A two-hour task might be two hours of work, or twenty minutes of work plus an hour and forty minutes waiting on a permission prompt. The first means the task is big. The second means the human is the bottleneck, and the fix is a broader permission rule, a better prompt, or handing it off at a different time of day. Worked and needs input are separate numbers, so you know which one you have.

Blocked stops being invisible. Before, you saw a blocked task only if you looked while it was blocked. Now every blocked stretch stays on the record with its length, and the dashboard shows which workspace keeps getting stuck.

Improvements become measurable. Change a prompt, a skill or a workflow, and watch whether the typical start to close drops the next week. One fast task proves nothing. A p50 over a week of tasks does.

What are the trade-offs?

No backfill of history. History that was never recorded can't be rebuilt. Existing tasks start their timeline at their next status change. (The dashboard does backfill from whatever history exists, once, on the first boot after the upgrade.)
p50 is an estimate. It comes from a mergeable histogram, not from sorting every task. That's the price of rolling up months of data cheaply.
One more write per status change. It's small, and it happens inside a transaction we were already opening.
A derived state depends on every path that can answer a question. "Needs input" is right only because every way a question gets asked or answered re-checks it. That's why the logic lives in the storage layer and not in the individual features.
The enum is a one-way door. You can add states. You can never remove, rename or reorder the stored ones.

FAQ

Why not full event sourcing?
Too much for this. The status is read in many places, including by agents over MCP. An append-only history beside the current status gets the durations without migrating every reader.

Why not work out durations from the message thread?
Messages and status changes are different streams. An agent can go blocked without writing anything, and a quiet agent can be working for 30 minutes. A dedicated history records exactly what changed and when.

Does "needs input" change a task's status?
No. It exists only in the history. Queues, counts, filters and agents see the same status as before.

Why does the dashboard show p50 instead of the average?
Agent task durations have a long tail. One task blocked over a weekend drags the average far from anything typical. The median doesn't move, and max is right next to it for finding the outlier.

Which states can appear?
Not started, ongoing, blocked, needs input, completed, rejected, and scheduled for recurring or one-time scheduled tasks.

Try it

The change is in agentrq/agentrq#756, and the Task Timeline feature page has the short tour. Open any task that has changed status since the update and look under the description.

Question for you: if you run agents against a task queue, how do you tell "the agent was slow" from "I was slow"? Do you track human wait time separately, or does it all go into one latency number?

Originally published on the AgentRQ blog.

Single Responsibility for AI Agents: One Workspace, One Job

Mustafa Turan — Mon, 28 Sep 2026 04:29:21 +0000

You would never ship a God class that handles billing, email templates, database migrations and the marketing site. So why do so many of us run exactly that as an AI agent?

I did, for months. One agent, one workspace, every repository, every note I had ever written, and a mission description trying to cover a whole company. It was never bad. It was never great at anything either. It wrote landing page copy in the tone of a commit message. It suggested a database migration in the middle of a blog post. It applied a rule from one project to another where that rule was flat-out wrong.

So I refactored it the way I would refactor code: one workspace, one job. This post covers what that means in practice, the two reasons it works, how isolated agents still collaborate (pub/sub, not DMs), and the places where I think you should disagree with me.

TL;DR

An AI agent's memory is only useful if every note in it is true for every task it runs. Mixing jobs breaks that.
Everything an agent loads at the start of a task, it pays for on every turn. A narrow job means a small starting context.
Isolated workspaces coordinate through events (publish/subscribe) and one supervisor agent, never agent-to-agent messages.
Split where the knowledge diverges, not where the task names differ.

What is an isolated, single-purpose AI agent workspace?

I build AgentRQ, so that is the vocabulary I will use, but the idea is tool-agnostic. A workspace is the unit an agent connects to. It holds:

a mission the agent reads when it starts a task,
a task board with the history of every job,
a memory the agent reads and writes (loadMemory / saveMemory over MCP),
a set of skills it can search and load.

"Single-purpose" is just a discipline on top: one workspace, one definition of done. Not "engineering". Something closer to "the static marketing site and its SEO content." If you can't describe success in one sentence, the scope is too wide.

Today I run a handful: static site, core app, QA, support, social, outreach. They don't know about each other. That is the point.

Why does a shared workspace make AI agent memory go bad?

This is the part I underestimated most.

Agent memory rots in a specific way when jobs share it: a lesson that is true in one context gets applied in another where it is false.

# app repo:     "Always run the migration before deploying."   ✅ gospel
# static site:  "Always run the migration before deploying."   ❌ nonsense

# static site:  "The Markdown converter has no italics; use bold."  ✅ vital
# app repo:     "The Markdown converter has no italics; use bold."  🤷 noise

Put both in one pile and the agent has to guess which rules apply, on every task. Sometimes it guesses wrong, confidently. It's the agent equivalent of a global mutable config shared between services.

In a single-purpose workspace, every note is about the same system. The workspace that builds our site has a memory index of about forty entries, and every one of them is about that site: the converter has no italics or blockquotes, headings render as plain text, the CSS hash changes on every build and that diff churn is expected, slugs should be long and descriptive. None of those would survive contact with another project. Here, all of them are simply true.

Two side effects I didn't expect:

The agent writes memory freely. I don't have to curate defensively, wondering whether a note will leak into the wrong context. The agent writes down whatever would have saved it a detour, and the next run skips the detour. Learning compounds instead of colliding.
I can actually review it. Opening one workspace's memory is reading the operating manual for one job. I can spot a wrong note in a minute. A mixed memory is a junk drawer, and nobody audits a junk drawer.

How much context does an AI agent really need to start a task?

Only what the job needs, and the difference adds up.

Before an agent does any work, the mission, the memory index, the skill descriptions and the instructions all go into its context window. In a stateless tool-calling loop, that prefix is re-sent on every turn.

A do-everything workspace has a do-everything prefix. The mission explains five businesses. The memory index lists notes for all of them. The skill list offers a release playbook to an agent writing a tweet. Most of it is noise for the task at hand.

A single-purpose workspace starts smaller because there is less to say. I haven't benchmarked the exact saving (it depends entirely on how big your notes get and how long your tasks run), so I won't invent a number. The shape is simple arithmetic, though:

cost ≈ starting_context × turns + work

Shrink the first term and you save on every turn of every task.

Tokens are the smaller half. The bigger half is attention: an agent whose window is full of relevant context makes better decisions than one that has to ignore half of what it was handed. I pair this with Clear Context, which starts every task on a clean window, for the same reason.

How do isolated AI agents collaborate without sharing context?

The obvious objection: a feature has to be built, tested, released, written up and announced. No single workspace owns all of that.

The workspaces are isolated from each other's context, not from each other's work. They coordinate in two ways, and neither involves one agent reading another's memory.

1. A supervisor agent that sees everything

One supervisor agent connects to an account-wide Supervisor MCP instead of a single workspace. It can see every workspace, task and status; create tasks anywhere; and move a task that landed in the wrong place.

When I want a feature shipped end to end, I brief the supervisor once. It hands the core app its half, the static site its half, and outreach its half, each written for that workspace. The workers stay narrow; the supervisor is the one place allowed to be broad. And it has a single job too: dispatching, not doing.

2. Events, not direct messages

For routine hand-offs I don't want a supervisor in the middle. The workspaces talk through events, which is plain publish/subscribe:

A workspace finishes something and publishes a named event with a short payload.
AgentRQ finds every trigger subscribed to that name.
Each subscribed workspace gets a new task, with the payload in the task body.

The publisher doesn't know who is listening. The listeners don't know who published. The event name is the only contract.

These are the events my workspaces actually run on:

Event	Published when	Who picks it up
`code_changed`	Core app merges a change	QA runs its checks
`qa_failed`	QA finds a regression	Core app gets a fix task, failure attached
`bug_fixed`	Core app lands the fix	QA re-checks, Support tells the reporter
`feature_released`	A release goes out	Static site drafts a post, updates feature pages
`blog_published`	A post goes live	Social turns it into an X thread
`x_thread_created`	The thread is posted	Outreach adds it to follow-ups

Every name is past tense, on purpose. An event reports a fact any workspace can react to in its own way. fix_the_bug would be a command aimed at one agent, which is just a direct message wearing an event's name.

A trigger can also name the event to fire when its task completes, so the chain wires itself. Here is the release part of it as a workflow called release_cycle, spanning five workspaces. Note the fan-out on bug_fixed: Support notifies reporters while Core App cuts the release, in parallel.

I ran it once on a local dev build to check it behaves like the table says. I created exactly one task, a Core App merge that published code_changed. Every task after that was created by an event. Each workspace did its part over its own connection, knowing only its own mission:

Outreach isn't even in that workflow. It subscribes to x_thread_created on its own. The chain grows at the edges without anyone rewiring the middle.

Why not just let agents message each other?

Same reason you put a queue between microservices instead of having every service call every other one:

Coupling. An agent that can DM any other agent has to know who they all are and what each does. That is exactly the cross-domain context I kept out of its window.
Combinatorics. Point-to-point links grow as n(n-1)/2. Five workspaces is already 10 conversations to keep straight, each a place for a request to get lost or answered twice. With events, adding a sixth workspace is one new trigger.
Observability. Every hand-off is a task with a title, a body describing what happened upstream, and a status on the board. When a chain breaks, I'm reading tasks, not reconstructing a group chat between bots.

What does isolating AI agents actually unlock?

Agents get good at one job and stay good. The workspace that runs our site has closed more than ninety tasks, and lessons from the first ones are still in its memory, still true, still read before every new task.
Delegation without re-explaining. I send a one-paragraph brief from my phone. The workspace already knows the tone, the build steps, the formatting quirks and what I rejected last time. That's the difference between delegating a task and babysitting one.
A small blast radius. A bad note or a confused agent can only damage one job. When outreach learns something wrong, the release process doesn't notice.
Cheap agent swaps. The knowledge lives in the workspace, not in one vendor's config file. Point a different coding agent at the workspace and it inherits the mission, memory and skills on day one.

The pitfalls I actually hit

Going too narrow. After the first split I split everything: blog posts, glossary terms, feature pages, each in its own workspace. Same repo, same build, same quirks, and I was teaching three agents the same lessons. The rule now: split where the knowledge diverges, not where the task names do. If two jobs would write the same notes, they belong together.

Genuinely shared knowledge. Some rules are universal: how PRs are described, which branch never gets a direct push. Copying them into every workspace is the same rot, spread thinner. Keep memory for what's local and put what's universal in something shared. In AgentRQ that's skills shared across workspaces: fix a playbook once, fixed everywhere.

Work that crosses the line. A launch needs code in the app and a post on the site. I don't create a third workspace; I split it into two tasks, via the supervisor or a feature_released event. A task that lands in the wrong workspace gets moved, with its history.

Memory still goes stale. Isolation keeps memory relevant, not current. Tools get upgraded, a limitation gets fixed, and the note warning about it becomes a lie. Tell the agent to correct or delete a note when it finds one that no longer holds.

Setup cost. A new workspace needs a mission, a connected agent and a few tasks before its memory is worth anything. Isolation pays back on work that repeats, not on one-offs.

Where you should push back

"Context windows are huge now, just give it everything." Windows have grown, and strong models ignore a lot of noise. But every token is still billed on every turn, and ignoring noise is a skill models have, not one they are perfect at. If your contexts are small and cost isn't a concern, this argument carries real weight.

"A generalist sees connections a specialist misses." The strongest objection, and true. My narrow workspaces will never notice on their own that a new feature deserves a post. The supervisor and events cover the connections I already know about, but a dispatcher over narrow workers isn't one mind holding everything. If cross-domain insight is your main value, a generalist may serve you better.

"Just use retrieval over one big memory." Works when retrieval is good; fails quietly when it isn't. The wrong note ranks high and the agent acts on it. Isolation is blunter, but it fails loudly: you can always see which workspace you are in.

"Overkill for small projects." Often, yes. One repo and one kind of work? One workspace is the single-purpose workspace.

"Teams need shared context, not silos." For teams, boundaries should follow ownership and on-call lines, not one person's mental model. What I describe is shaped for one person running many jobs.

FAQ

What is a single-purpose AI agent workspace?
A workspace scoped to one job with one definition of done, holding its own mission, memory, skills and task history, so an agent working in it only ever loads context that is relevant to that job.

Does isolating AI agents reduce token usage?
Usually. The mission, memory index and skill list are loaded at the start of every task and re-sent on every turn, so a narrower workspace means a smaller fixed cost per turn. The exact saving depends on your notes and task length.

How do isolated AI agents hand off work?
Through publish/subscribe events (a workspace publishes a past-tense event like bug_fixed; subscribed workspaces receive a new task) or through a supervisor agent with account-wide visibility that creates tasks in each workspace.

When should I keep one workspace instead of splitting?
When every note in your agent's memory is true for every task it runs. If you catch yourself writing "except in the other project" into a note, that workspace probably wants to become two.

Try it on one job

None of this is a law. It's the setup that fits one person running many unrelated jobs and wanting to delegate and walk away. I know people who run one giant workspace very productively, people who spin up a workspace per feature and throw it away on ship, and teams who isolate by customer instead of function.

So take the question, not my answer: is every note in your agent's memory true for every task it will run? If not, split one job out, give it a week of tasks, and read its memory at the end.

How do you scope your agents: one generalist, many specialists, or something else? I'd like to hear what's working for you in the comments.

Originally published on the AgentRQ blog. AgentRQ is a human-in-the-loop task manager for AI agents: agentrq.com.

DEV Community: AgentRQ

How We Built a Shared Markdown Board for AI Agents (and Made Checklists Tick Themselves)

What problem are we solving?

What is a Pano doc?

Why can't agents search the Pano?

How does an assigned checklist item follow its task?

Step 1: assigning writes a link into the markdown

Step 2: a status change triggers a server-side rewrite

Step 3: the write is a sync, not a save

Step 4: open boards update live

How do two agents avoid overwriting each other?

Every doc has a version

The check happens in the UPDATE itself

A conflict tells the agent exactly what to do

edit: change a line without resending the doc

What humans see on a conflict

How do @mentions turn into tasks?

What stops the board from filling up forever?

What are the rules for files?

What does this unlock?

FAQ

Copilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip

Why does "YOLO" mean two different things in Copilot?

What exactly does copilot --yolo turn on?

How do the in-session commands map onto each other?

Why isn't Autopilot the same thing as YOLO?

Can I get most of the speed without approving everything?

How does VS Code's version work?

Are terminal allowlists enough to keep me safe?

What does the sandbox actually enforce, and what doesn't YOLO touch?

Can a cloned repo flip YOLO on for me?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Gemini CLI YOLO mode, read from the source: why settings.json can't turn it on

Who is this even for in late 2026?

What does Gemini CLI actually do with an approval mode?

Why can't I just put "yolo" in settings.json?

Does YOLO turn the sandbox on?

How do Ctrl+Y and Shift+Tab interact?

What happens in CI and headless runs?

What are the halfway options?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

How to Enable Claude Code Channels for Team and Enterprise Plans (Step by Step)

TL;DR

What are Claude Code Channels, and why are they off for my org?

Who can enable Channels?

Step 1: Open Organization settings

Step 2: Go to Products → Claude Code and find Channels

Step 3: Confirm it says "Set by admin"

Step 4: Connect a channel (AgentRQ, Telegram or Discord)

Option A: AgentRQ

Option B: Telegram

Option C: Discord

Can I enable Channels with managed settings instead?

How do I restrict which channel plugins can run?

What should admins think about before turning it on?

FAQ

Codex CLI YOLO mode: two knobs, one flag, and why --yolo also kills the sandbox

What are the two knobs?

Why does Codex's YOLO also drop the sandbox?

How is the sandbox actually built?

How do I get most of YOLO without dropping the fence?

How does config precedence work, and where does project trust fit?

How does the in-session switch work?

What changes in CI with codex exec?

How does YOLO map over ACP?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Claude Code YOLO mode: what --dangerously-skip-permissions really turns off (and what it doesn't)

Why does "skip permissions" not mean "no guardrails"?

What survives bypass mode?

How do you actually turn it on?

Why can't a cloned repo flip YOLO on for you?

Why won't --dangerously-skip-permissions run as root?

Why isn't bypass in my Shift+Tab cycle?

Is auto mode just YOLO with extra steps?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

There is no agy --yolo. How YOLO mode actually works in Antigravity (IDE and CLI)

`edit`: change a line without resending the doc

Why are people typing `agy --yolo` in the first place?