blacktops
Agentic SDLC · AI FDEJoin the waitlist
Insights / October 31, 2026

16 coding agents compared: where they run, tools, permissions and logs

We read the documentation for 16 coding agents on 28 October 2026 and wrote down what it says about four things: where the agent runs, what tools it supports, what it can do without asking, and what it leaves behind for a reviewer. Everything below comes from the products’ own documentation pages and nowhere else. Where a page doesn’t answer, the entry says “docs do not say”.

This is not a test, a ranking or a recommendation. Documentation tells you how a product works, not how well it works, and none of these pages carries a version date. The products are in alphabetical order, so skim the table and go straight to the ones your team uses.

The four checks are the ones from What should you check before you add another coding agent?.

The short version

The docs for 14 of the 16 cover MCP. Fourteen say the agent reads AGENTS.md. Fourteen name a mode, flag or setting that approves actions without asking. Six document OpenTelemetry export, and in all six it’s off until somebody turns it on. Eleven don’t say how the agent’s commits or pull requests are attributed.

At a glance

Where the docs say each product runs, and whether they document MCP (Model Context Protocol) tool servers.

Product Where it runs, and MCP
Aider Command line
MCP: docs do not say
Augment Code CLI, VS Code and JetBrains, vendor cloud, self-hosted
MCP: yes
Claude Code Terminal, IDE, desktop, browser, CI, vendor cloud, self-hosted (beta)
MCP: yes
Cline Editors, desktop app, CLI (also headless in CI)
MCP: yes
Codex CLI, IDE, desktop app, CI, vendor cloud
MCP: yes
Copilot coding agent and CLI GitHub Actions environment; terminal
MCP: yes (cloud agent: no OAuth servers)
Cursor Editor, CLI, vendor cloud VMs
MCP: yes
Devin Vendor cloud VM, CLI, your computer through Local Hands
MCP: yes
Gemini CLI Terminal, headless
MCP: yes
Goose Desktop app, CLI, a server you run
MCP: yes
Jules Vendor cloud VM only
MCP: docs do not say
Junie CLI, JetBrains IDEs, CI, GitHub Action
MCP: yes
Kiro IDE, CLI (also headless in CI), vendor cloud sandbox
MCP: yes
OpenCode Terminal, desktop app, IDE, GitHub Actions
MCP: yes
Roo Code VS Code extension
MCP: yes
Windsurf (now Devin Desktop) Editor, on your machine
MCP: yes

What stood out across the docs

One caution before the counts: they’re counts of what the pages say, not of what the products can do. A product whose page is silent may still have the feature.

  • MCP: Of the 16, the docs of 14 document MCP; Aider’s and Jules’s don’t mention it. Nine describe OAuth sign-in for remote servers: Claude Code, Codex, Cursor, Devin, Gemini CLI, Goose, Junie, OpenCode and Windsurf. GitHub’s say Copilot cloud agent doesn’t currently support OAuth servers; Kiro’s and Roo Code’s don’t mention OAuth; Cline’s and Augment Code’s mention it only in passing.
  • Instruction files: The docs of 14 say the agent reads AGENTS.md. Gemini CLI’s can be set to; Aider’s load a conventions file you name. Five also read a file named for another product: Augment Code, Cline, Copilot, Devin CLI and OpenCode.
  • Sandbox: The docs of five describe a local sandbox that stays off until turned on: Claude Code, Copilot CLI, Devin CLI, Gemini CLI and Junie CLI. Codex’s describe one that’s on by default. Windsurf’s (Devin Local) describe one with no stated default; Kiro’s sidebar names one whose page wasn’t found. Cursor’s MCP page lists “No sandbox” as a mode for admin-approved local MCP servers. The other seven describe none.
  • Approve everything: The docs of 14 name a mode, flag or setting that approves actions without asking: Aider, Claude Code, Cline, Codex, Copilot CLI, Cursor, Devin, Gemini CLI, Goose, Junie, Kiro, OpenCode, Roo Code and Windsurf. In Goose’s docs it’s the default mode. Augment Code’s (per-tool allow rules only) and Jules’s don’t. Four name an admin setting that turns it off or caps it: Claude Code, Cline, Codex and Windsurf.
  • OpenTelemetry: The docs of six document OpenTelemetry export: Claude Code, Cline, Codex, Copilot, Gemini CLI and Goose. Each is off until someone enables it. Once it’s on, Gemini CLI logs prompts by default; Claude Code, Codex, Copilot and Goose leave prompt or message content out by default; Cline’s page doesn’t say.
  • Attribution: The docs of five say how the agent’s commits or pull requests are attributed: Aider, Claude Code, Copilot, Devin and Jules. The pages read for the other 11 don’t say.

Aider

Aider’s docs describe a command-line tool configured with aider options and a .aider.conf.yml file.

Where it runs: The command line. The pages read name no cloud, CI or self-hosted mode.
Tool support: MCP: docs do not say. Instructions: a file such as CONVENTIONS.md, loaded with --read. Config: .aider.conf.yml, AIDER_ environment variables or a .env file.
Permissions: No approval rules are documented. --yes-always says yes to every confirmation.
Review evidence: Chat history goes to .aider.chat.history.md by default. “Whenever aider edits a file, it commits those changes with a descriptive commit message.” Those commits add (aider) to the author and committer names, and --no-auto-commits turns committing off. Analytics are opt-in.
Docs do not say: a sandbox, network controls, managed settings, log retention or OpenTelemetry. The options page and the git page describe the co-authored-by setting differently, so this entry states no default for it.

Sources, as of 28 October 2026: Aider’s git integration page, Aider’s options reference, Aider’s configuration page, Aider’s conventions page, Aider’s analytics page.

Augment Code

Augment Code’s docs cover the Auggie CLI, VS Code and JetBrains extensions, and Cosmos cloud and self-hosted environments.

Where it runs: Auggie in a terminal, with a print mode for automation and CI/CD; IDE extensions; Cosmos environments on Augment-hosted compute, or on your own infrastructure through daemons.
Tool support: MCP: yes; stdio (the default), SSE and HTTP in the CLI. OAuth: mentioned only for one-click IDE integrations. Instructions: .augment/rules/, AGENTS.md, CLAUDE.md, .augment-guidelines. Config: settings.json at managed, workspace and user level.
Permissions: CLI rules are allow, deny, ask-user, webhook-policy or script-policy; across policies, the most restrictive match wins. One rule on bash covers every shell command. The page says the rules are not enforced in the IDE extension. Cosmos cloud environments have outbound network access only. The CLI reference lists no bypass flag.
Review evidence: CLI sessions are saved unless you pass --no-session. In Cosmos, “A Session’s conversation is saved indefinitely — it doesn’t expire.” If a PreToolUse hook times out or crashes, the tool still runs.
Docs do not say: what the CLI does when no rule matches, a CLI sandbox, telemetry, OpenTelemetry, or commit or PR attribution.

Sources, as of 28 October 2026: Auggie CLI overview, Auggie permissions, Auggie hooks, Auggie CLI reference, Auggie settings, Auggie MCP integrations, Augment MCP setup, Augment guidelines and rules, Cosmos cloud environments, Cosmos sessions.

Claude Code

Anthropic’s docs describe Claude Code in the terminal, IDEs, a desktop app, the browser and CI.

Where it runs: On your machine; in CI through GitHub Actions or GitLab CI/CD; in cloud sessions on Anthropic’s infrastructure; and in self-hosted environments (public beta, off by default).
Tool support: MCP: yes; stdio, HTTP, SSE and WebSocket; OAuth through /mcp. Instructions: CLAUDE.md at several levels, .claude/rules/, and AGENTS.md in place of CLAUDE.md. Config: settings.json at user, project, local and managed level; .mcp.json.
Permissions: The default mode asks before shell commands, edits and web fetches, except built-in read-only commands. Deny rules are checked first, then ask, then allow. The sandbox wraps shell commands, is off by default and doesn’t run on native Windows. Bypass: bypassPermissions: “Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage.” Managed settings can disable it.
Review evidence: Transcripts are deleted after cleanupPeriodDays (30 days by default for subagent transcripts). OpenTelemetry is off until enabled, prompt content stays off by default, and a repository’s settings can’t switch it on. Commits get a Co-Authored-By trailer by default.
Docs do not say: whether the client is open source, or whether transcripts are complete or tamper-evident.

Sources, as of 28 October 2026: Claude Code overview, Claude Code MCP, Claude Code memory and CLAUDE.md, Claude Code permissions, Claude Code sandboxing, Claude Code settings, Claude Code settings reference, Claude Code monitoring, Claude Code subagents, Claude Code self-hosted environments.

Cline

Cline’s docs describe one agent for VS Code, JetBrains IDEs, other editors, a desktop app and a CLI.

Where it runs: On your machine: VS Code, JetBrains IDEs, Cursor, Windsurf, Zed and other editors, Cline Desktop, and a CLI with a headless mode for CI/CD.
Tool support: MCP: yes; STDIO, Streamable HTTP and SSE (labeled legacy). OAuth: one CLI action for browser authorization, flow not described. Instructions: .clinerules/, AGENTS.md; .cursorrules and .windsurfrules are detected. /newrule has Cline write a rule.
Permissions: The pages state different defaults. The getting-started page says every action needs your explicit approval. The CLI page lists --auto-approve with a default of true: “Autonomous execution can modify files and run commands without further prompts.” The model marks which commands need approval; there’s no fixed allowlist. Admins can disable YOLO Mode with "yoloModeAllowed": false.
Review evidence: Each task’s full conversation, with tool inputs and outputs, is stored locally, with optional backup to your own bucket. Usage telemetry is on by default. OpenTelemetry is opt-in.
Docs do not say: a sandbox, network controls, a command denylist, or commit or PR attribution.

Sources, as of 28 October 2026: What is Cline, Cline auto-approve, Cline CLI overview, Cline MCP overview, Cline rules, Cline YOLO mode for enterprises, Cline prompt storage, Cline telemetry, Cline OpenTelemetry.

Codex

OpenAI’s docs describe Codex as a CLI, IDE extension and desktop app, plus Codex Cloud. Its developers.openai.com pages now redirect to learn.chatgpt.com.

Where it runs: On your machine; through codex exec in scripts and CI; and as Codex Cloud tasks. Defaults change by place: a version-controlled folder starts in Auto (edits and commands in the workspace), other folders in read-only, and codex exec in a read-only sandbox.
Tool support: MCP: yes; STDIO and Streamable HTTP; OAuth through codex mcp login. Instructions: AGENTS.md. Config: ~/.codex/config.toml, project .codex/config.toml (trusted projects only), admin requirements.toml.
Permissions: The sandbox (what Codex can touch) and the approval policy (when it asks) are separate settings. Locally the sandbox is on by default, OS-enforced, with network off. Codex Cloud blocks internet during the agent phase by default. Admins’ requirements.toml can block --ask-for-approval never and danger-full-access, including --yolo. “Cloud environments don’t inherit local device policy, MDM settings, or local network access.” Bypass: --sandbox danger-full-access or the --dangerously-bypass-approvals-and-sandbox flag.
Review evidence: Local transcripts are saved by default under CODEX_HOME. OpenTelemetry export is off until you add [otel], with prompt text redacted by default. Enterprises get a Compliance API.
Docs do not say: commit or PR attribution, or transcript retention. The CLI’s repository lists the Apache-2.0 license.

Sources, as of 28 October 2026: Codex CLI repository, Codex approvals and security, Codex MCP, Codex advanced configuration, Codex Cloud internet access, Codex enterprise admin setup, Codex managed configuration.

Copilot coding agent and Copilot CLI

GitHub’s docs now call the coding agent “Copilot cloud agent”. Copilot CLI is the terminal agent.

Where it runs: Cloud agent: an ephemeral environment powered by GitHub Actions, with self-hosted runners as an option. CLI: a terminal on Linux, macOS or Windows, or a cloud-hosted session. The CLI’s local sandbox is off until you enable it, then applies to every session; enterprise managed settings can require it.
Tool support: MCP: yes. The cloud agent uses MCP tools without asking and doesn’t currently support remote servers that use OAuth. The CLI page doesn’t name transports. Instructions: .github/copilot-instructions.md, AGENTS.md, or a single root CLAUDE.md or GEMINI.md.
Permissions: The cloud agent has no per-command prompts, pushes only to a copilot/ branch or the pull request’s branch, and a human must merge its pull requests. Its firewall is on by default: “The firewall only applies to processes started by the agent via its Bash tool.” The CLI asks before tools; --deny-tool wins over --allow-tool, and --allow-all-tools or /yolo skips approvals.
Review evidence: Cloud agent session logs on GitHub.com show the work and tools used. Copilot authors the cloud agent’s commits, with the developer who started the task as co-author. Copilot CLI keeps sessions in ~/.copilot/session-state/ and can sync them to GitHub.com. Enterprises can enable OpenTelemetry export, which by default leaves out prompts, responses, tool arguments and tool results.
Docs do not say: a retention period for session data, the CLI’s MCP transports, or whether Copilot CLI is open source.

Sources, as of 28 October 2026: Copilot on GitHub, including cloud agent, Copilot cloud agent risks and mitigations, the Copilot agent firewall, extending Copilot cloud agent with MCP, Copilot repository instructions, About Copilot CLI, Copilot OpenTelemetry for agent monitoring, Copilot session data, Copilot CLI local sandboxing.

Cursor

Cursor’s docs cover the editor’s Agent, the Cursor CLI and cloud agents.

Where it runs: The editor and the CLI on your machine; cloud agents in VMs with full development environments.
Tool support: MCP: yes; stdio, SSE and Streamable HTTP; OAuth. Each MCP connection, and then each tool call, needs approval. Instructions: .cursor/rules, AGENTS.md, User and Team Rules. Config: mcp.json and hooks.json at user and project level, plus an enterprise hooks.json.
Permissions: Sensitive actions and terminal commands need approval by default. “Agents can modify workspace files without approval, except for configuration files.” The page calls run modes best-effort guardrails, not a hard boundary. In the CLI, permissions.allow, permissions.deny and --force control what runs without prompts, and deny rules win. By default agents can’t make arbitrary network requests. Admins can enforce workspace trust through MDM and restrict cloud agents’ outbound domains.
Review evidence: Checkpoints are stored locally, separate from Git. Cloud agents keep transcripts, run events and setup logs. Hooks fail open by default; failClosed: true changes that.
Docs do not say: a sandbox for terminal commands (the MCP page gives admin-approved local MCP servers a network mode, including “No sandbox”), telemetry, OpenTelemetry, retention, or commit or PR attribution.

Sources, as of 28 October 2026: Cursor agent security, Cursor MCP, Cursor rules, Cursor cloud agents, Cursor hooks, Cursor CLI permissions, Cursor agent overview.

Devin

Cognition’s Devin docs cover cloud sessions (web app, Slack, API) and the Devin CLI. Devin Local, inside Devin Desktop, is under Windsurf below.

Where it runs: Cloud sessions in a Linux VM booted fresh from a snapshot; the page doesn’t say where it’s hosted. The CLI runs on your machine. Local Hands lets a cloud session use your computer.
Tool support: MCP: yes; stdio, SSE and HTTP; OAuth, with devin mcp login in the CLI. Instructions: AGENTS.md; the CLI also reads CLAUDE.md, .cursor/rules/, .windsurf/rules/ and others.
Permissions: Cloud: security profiles set a network allowlist and an MCP allowlist; without one, sessions can use any MCP server installed in the organization. CLI: Normal mode by default (reads approved; writes and shell commands ask), plus Accept Edits, Smart, Bypass and Autonomous. A deny rule always wins, and organization rules can’t be overridden. “Users choose whether to pass --sandbox. No enforcement.” Admins can require it.
Review evidence: The cloud Progress tab logs commands, edits and browser activity in one view. Settings choose whether pull requests open as Devin or as you. The CLI’s attribution option, on by default, adds a Co-Authored-By: Devin trailer.
Docs do not say: network defaults without a security profile, log retention, telemetry defaults, OpenTelemetry, or the CLI flag for Bypass.

Sources, as of 28 October 2026: Devin environment, Devin security profiles, Devin MCP, Devin Local Hands, Devin session tools, Devin GitHub integration, Devin CLI sandbox, Devin CLI permissions, Devin CLI config file, Devin CLI rules.

Gemini CLI

Google’s Gemini CLI is a terminal agent under the Apache-2.0 license. Its docs were read from the project’s GitHub main branch, which changes with each commit.

Where it runs: The terminal, plus a headless mode. The pages read describe no cloud or CI product.
Tool support: MCP: yes; stdio, SSE and Streamable HTTP; OAuth 2.0 for remote servers. Instructions: GEMINI.md; context.fileName can add names such as AGENTS.md. Config: ~/.gemini/settings.json, plus policy files at user and admin level.
Permissions: The default mode asks before most write tools. Policy rules are allow, deny or ask_user; the highest priority wins, and admin policies override the rest. “Defining policies in a workspace’s .gemini/policies directory will not have any effect.” The sandbox is opt-in (-s), through Seatbelt, Docker, Podman, gVisor and others. Bypass: yolo mode; trust: true on an MCP server skips its confirmations.
Review evidence: Built-in OpenTelemetry, off by default. Once it’s on, logPrompts defaults to true.
Docs do not say: stored session transcripts, retention, or commit or PR attribution.

Sources, as of 28 October 2026 (main branch): Gemini CLI repository, GEMINI.md files, Gemini CLI MCP servers, Gemini CLI policy engine, Gemini CLI sandbox, Gemini CLI telemetry, Gemini CLI trusted folders.

Goose

Goose is an agent with a desktop app and a CLI. Its GitHub repository lists the Apache-2.0 license and says Goose is part of the Agentic AI Foundation (AAIF) at the Linux Foundation; its docs are at goose-docs.ai.

Where it runs: On your machine; goose serve can run on another machine for Goose Desktop to connect to. No vendor cloud.
Tool support: MCP: yes (extensions are MCP servers); stdio and Streamable HTTP; OAuth for remote extensions. GOOSE_ALLOWLIST limits extensions; unset, nothing is restricted. Instructions: AGENTS.md and .goosehints, looked for at each level by default; CONTEXT_FILE_NAMES sets others. Config: ~/.config/goose/config.yaml.
Permissions: “Autonomous Mode is applied by default.” The other modes are Manual Approval, Smart Approval and Chat Only. In Manual or Smart mode, each tool can be Always Allow, Ask Before or Never Allow. Adversary mode adds a reviewer agent, and lets the call through if the reviewer fails.
Review evidence: Sessions, with tool calls and results, sit in a local SQLite database; system logs are cleaned up after two weeks. Usage data is opt-in. OpenTelemetry export starts when an endpoint is set, with message content off by default.
Docs do not say: a sandbox, network controls, session retention, or commit or PR attribution.

Sources, as of 28 October 2026: Goose GitHub repository, Goose permission modes, Goose tool permissions, Goose extensions, Goose extension allowlist, Goose hints files, Goose config files, Goose logs, Goose usage data, Goose environment variables, Goose adversary mode, Goose remote server, Goose CLI commands.

Jules

“Jules is an experimental coding agent that helps you fix bugs, add documentation, and build new features.” It runs in Google’s cloud.

Where it runs: Each task runs in a short-lived Ubuntu VM with internet access, started from the web app, GitHub Issues or the Jules Tools CLI. No local or self-hosted mode is documented.
Tool support: MCP: docs do not say. Instructions: AGENTS.md in the repository root. Config: an optional setup script, which is run and snapshotted.
Permissions: Jules writes a plan for you to review and approve before it changes code, and you can step in at any time. The pages read describe no allow or deny rules, network controls or admin settings.
Review evidence: An activity feed explains each change inline, next to a diff view. Jules is the commit author. If Jules publishes the pull request it’s the creator; if you create it, you’re the author.
Docs do not say: MCP, network controls, secrets handling, admin settings, logs, telemetry, retention, or what the VM restricts.

Sources, as of 28 October 2026: Jules overview, Jules environment, Jules running tasks, Jules code and pull requests, Jules FAQ, Jules Tools CLI reference.

Junie

JetBrains’ Junie docs, dated 27 October 2026 in the page footer, cover Junie CLI, JetBrains IDEs and CI. They mark Junie CLI, its sandbox and headless mode as Early Access.

Where it runs: CLI on Linux, macOS or Windows; JetBrains IDEs; headless in CI/CD; a GitHub Action on your own runners. Non-interactive runs are trusted by design and load the project’s configuration without prompting.
Tool support: MCP: yes, one JSON format for CLI and IDE; remote servers over HTTP or HTTPS; OAuth. Instructions: .junie/AGENTS.md, then AGENTS.md; global ~/.junie/AGENTS.md. Config: config.json and mcp/mcp.json in ~/.junie or the project’s .junie; allowlist.json and sandbox.json in ~/.junie.
Permissions: Unless brave mode is on, it asks before most terminal commands, edits outside the project and MCP tools; brave mode On runs them without approval. Allowlist rules are allow or ask, and the first match wins. The sandbox is off unless you pass --sandbox: “MCP servers, hooks, and operations performed directly by Junie CLI outside those tools are not isolated by this sandbox.”
Review evidence: Saved sessions keep the full context, with a transcript.md per session. The page calls sandbox denials in the transcript diagnostic monitoring, not a complete audit.
Docs do not say: telemetry, OpenTelemetry, retention, a deny action, or commit authorship.

Sources, as of 28 October 2026: Junie CLI, Junie CLI action allowlist, Junie CLI MCP configuration, Junie guidelines and memory, Junie CLI configuration, Junie headless mode, Junie on GitHub.

Kiro

AWS’s Kiro docs cover an IDE and CLI on your machine and a web agent that works in a cloud sandbox.

Where it runs: IDE and CLI on macOS, Linux or Windows, with a headless CLI mode for CI/CD. The web agent works in a per-task cloud sandbox, where permissions.yaml and interactive approvals don’t apply.
Tool support: MCP: yes; stdio, HTTP or SSE in the IDE, CLI and web. OAuth: not covered. Instructions: steering files in .kiro/steering/; AGENTS.md. Config: permissions.yaml, enterprise managed-settings.json, .kiro/hooks/. Kiro always denies writes to its own permission and state files.
Permissions: With no permissions.yaml, workspace reads and common read-only commands run silently; everything else asks. In the IDE, Autopilot proceeds with allowed operations without prompting; Supervised prompts before any action. A deny rule always wins, and admin settings allow only deny and ask. In headless runs, every ask counts as deny.
Review evidence: Usage telemetry is on by default for Free Tier and individual subscribers; “Kiro enterprise users are automatically opted out of telemetry and content collection by AWS.” Enterprise prompt logs can go to an S3 bucket you choose.
Docs do not say: OAuth for MCP, transcript location or retention, OpenTelemetry, or commit or PR attribution. The sidebar names a local command sandbox page; its URL wasn’t found.

Sources, as of 28 October 2026: Kiro permissions, Kiro MCP, Kiro steering, Kiro privacy and security, Kiro data protection, Kiro autonomous agent, Kiro web sandbox, Kiro enterprise monitoring, Kiro CLI, Kiro hooks.

OpenCode

OpenCode’s docs describe an open-source agent with a terminal interface, a desktop app and an IDE extension.

Where it runs: On your machine; opencode serve listens on 127.0.0.1:4096 by default. The GitHub integration runs in your GitHub Actions runners.
Tool support: MCP: yes, local and remote servers in opencode.json; OAuth handled automatically, with Dynamic Client Registration. Instructions: AGENTS.md, falling back to CLAUDE.md. Managed config files and macOS MDM override other config.
Permissions: Each rule is allow, ask or deny, and the last matching rule wins. Most permissions default to allow; external_directory defaults to ask, and .env reads need approval. On opencode --auto, the page says: “Auto mode only changes requests that would otherwise ask for approval.” Policies are experimental and not enforced in OpenCode 1.
Review evidence: Sessions sit in a local database and export to JSON, with --sanitize to redact. Snapshots are on by default, for rollback.
Docs do not say: a sandbox, network controls, telemetry, OpenTelemetry, session retention, or co-author trailers.

On the MCP OAuth fix. Pillar Security reported an MCP OAuth flaw fixed in 1.18.33. The opencode.ai changelog covers OpenCode 2 and lists MCP OAuth fixes, but neither it nor the 1.18.33 release notes name that flaw, an advisory or a CVE, and the 1.18.33 notes list no OAuth fix. The report and its caveats are in What should you check before you add another coding agent?.

Sources, as of 28 October 2026: OpenCode intro, OpenCode permissions, OpenCode MCP servers, OpenCode rules, OpenCode config, OpenCode policies, OpenCode GitHub integration, OpenCode server, OpenCode CLI, OpenCode changelog, OpenCode v1.18.33 release notes.

Roo Code

Roo Code’s docs describe a VS Code extension that also installs in Cursor, VSCodium and Windsurf. The GitHub API reports its repository as archived, last pushed 15 May 2026; the docs’ latest update note is 3.50.0 (19 February 2026), and the pages read don’t mention archiving.

Where it runs: In the editor, with models from external providers or local ones through Ollama or LM Studio. The install page mentions no CLI or cloud.
Tool support: MCP: yes; STDIO, Streamable HTTP and SSE. OAuth: not mentioned. Instructions: .roo/rules/, .roorules, and AGENTS.md by default. Config: mcp_settings.json, .roo/mcp.json.
Permissions: Auto-approve runs only when it’s enabled and at least one permission is selected. Command prefixes go on allowed and denied lists, and a deny wins when it’s as specific or more; adding * to the allowed list allows all commands. Reads stay in the workspace by default. .rooignore covers only a set list of file-reading commands.
Review evidence: “Checkpoints are enabled by default.” They’re snapshots in a shadow Git repository, not taken before commands. PRIVACY.md says telemetry is on by default and excludes code and prompts.
Docs do not say: task history location or retention, network controls, managed settings, OpenTelemetry, or commit or PR attribution.

Sources, as of 28 October 2026: Roo Code auto-approving actions, Roo Code MCP, Roo Code custom instructions, Roo Code checkpoints, Roo Code .rooignore, Roo Code installation, Roo Code FAQ, Roo Code update notes, Roo Code PRIVACY.md, GitHub API record for the Roo Code repository.

Windsurf

Windsurf’s docs now redirect to docs.devin.ai, where the editor is called Devin Desktop (Windsurf), with two local agents: Cascade and Devin Local.

Where it runs: In the editor on your machine. Both agents are unavailable while a workspace is in Restricted Mode.
Tool support: MCP: yes; stdio, Streamable HTTP and SSE, with OAuth for each. That page applies to Cascade; Devin Local uses the Devin CLI’s config. Instructions: .devin/rules/ or .windsurf/rules/, .windsurfrules, AGENTS.md, enterprise system rules. Config: ~/.config/devin/mcp_config.json. Cascade can write its own memories.
Permissions: Cascade’s terminal auto-execution levels are Disabled, Allowlist Only, Auto and Turbo, with no default stated; Turbo runs every command not on the deny list. Devin Local has allow, ask and deny rules, deny highest, and asks before MCP tools by default. Its OS-level sandbox has no stated default. Team admins can cap auto-execution and force the sandbox.
Review evidence: “Post-hooks cannot block since the action has already occurred.” Hooks can capture transcripts. A TelemetryLevel device policy exists, with no default stated.
Docs do not say: Cascade’s default mode, log location, retention, OpenTelemetry, or commit or PR attribution.

Sources, as of 28 October 2026: Cascade, Devin Desktop MCP, Cascade memories, Devin Desktop terminal, Devin Local, Cascade hooks, Devin Desktop admin controls.

How to keep this current

Documentation pages change without a version number, so an entry is only as good as the date next to it. If you want to refresh one, or hand the job to an agent, the steps below are enough to do it.

Run it

Terms:

  • Entry: one product’s section on this page: the five labeled lines and its “Sources” line.
  • Sources: the product’s own documentation pages, release notes or repository pages, with the URL and the date you read them. Not reviews, forums or news.
  • Default: what the product does with no setting changed.
  • Bypass: a mode, flag or setting the docs say approves actions without asking.
  • Silent: none of the pages read states the answer.

Inputs: The product name; its current entry from this page, as pasted text; the URLs in its “Sources” line; today’s date. Optionally, other pages from the same documentation site’s navigation or llms.txt index.

Steps:

  1. Open each URL in the entry’s “Sources” line. Record its HTTP status and any redirect target.
  2. Where a page moved, use the new URL and note the old one.
  3. Where it runs: list each place the pages say the agent runs (terminal, editor, CI, vendor cloud, self-hosted) and any default that changes by place.
  4. Tool support: record MCP (yes or no), its transports, OAuth for remote servers (yes or no), the instruction file names and the config file paths.
  5. Permissions: record the default approval behavior, the rule types and which rule wins, the sandbox and its default, network controls, admin settings, the bypass name, and what the page says a control doesn’t cover.
  6. Review evidence: record where session records are kept, whether they’re on by default and for how long; telemetry and OpenTelemetry defaults, and whether prompts are included; how commits and pull requests are attributed.
  7. After each answer, add the URL it came from. Copy the page’s own words for any default or limit.
  8. Where the pages are silent, write docs do not say. Never fill a gap from memory or another product’s page.
  9. Compare the new answers with the current entry and list every row that changed.

Output: This table, filled in. Copy it as it is.

| Row | Answer (page's words for defaults and limits) | Source URL, date read |
| --- | --- | --- |
| Product and docs location (note any redirect) | | |
| Where it runs | | |
| Defaults that change by place | | |
| Tool support: MCP, transports, OAuth | | |
| Tool support: instruction files | | |
| Tool support: config files | | |
| Permissions: default approval behavior | | |
| Permissions: rules and which wins | | |
| Permissions: sandbox and its default | | |
| Permissions: network controls; admin settings | | |
| Permissions: bypass mode or flag | | |
| Permissions: what the page says a control doesn't cover | | |
| Review evidence: session records, default, retention | | |
| Review evidence: telemetry and OpenTelemetry defaults | | |
| Review evidence: commit and pull request attribution | | |
| Docs do not say (list) | | |
| Rows changed since the current entry | | |

Unknowns: Where a page won’t load, or two pages disagree, write unknown and name who could supply the answer: the vendor’s documentation or support team for the product, or your own administrator for the settings in effect on your machines.

Done when: Every row holds an answer with a source URL and date, docs do not say, or unknown with who could supply it; every URL in the “Sources” line has a status; and the changed rows are listed.

Use the four checks on the agents you run

Everything above is what the docs say. None of it tells you which settings are actually in effect on your team’s laptops, runners and cloud accounts.

For that you have to run the four checks yourself, on each agent you use and in each place it runs, from your own settings files and run records. The method and a template are in What should you check before you add another coding agent?.

Where Blacktops fits

You don’t need any particular agent, or any particular tool, to use this. The entries above, checked against your own settings, are enough to get going.

Blacktops is the Agentic SDLC Platform designed to keep the customer’s question linked to the work. It maintains a single thread from the customer’s question through to the resolution:

  • the approved requirement
  • the agent’s work
  • the evidence
  • each decision and who made it
  • the update back to the customer

Agents do the work between decisions, and people make the decisions. That’s our operating model: Continuous Agentic Software Delivery™ (or Blacktops CASD™).

For people: spotted an entry that’s gone out of date? Get in touch with us and tell us the product, the page and what changed; we’ll re-read it. Just leave out credentials, customer names and anything else that’s confidential.

Related: What should you check before you add another coding agent? is the four-check method this comparison applies.

Continuous Agentic Software Delivery, CASD and Blacktops CASD are trademarks of Blacktops, Inc.