Continue's read-only mode still allows Bash
Run Continue CLI with --readonly and its built-in write tools disappear. Bash does not.
That behavior is documented. Continue's plan mode excludes Write, Edit, and other write tools, while allowing read tools and Bash. In the IDE extension, Plan mode filters the built-in tool set but does not filter MCP tools. A connected MCP server may still expose actions that change a local system or remote service.
This is not a newly disclosed vulnerability. It is a good example of how "read-only" can describe a client interface without describing the authority of the process underneath it.
The policy behind the label
Continue assigns each CLI tool one of three permission levels: allow, ask, or exclude. Read, List, Search, Fetch, and Diff are among the tools that default to allow. Write, Edit, MultiEdit, and Bash default to ask.
In an interactive session, ask can produce an approval prompt. Headless mode has nobody to answer, so Continue excludes tools set to ask. A normal headless run therefore begins conservatively unless the operator explicitly enables more tools.
Plan mode changes the precedence. Continue documents --readonly as an absolute override that excludes write tools, allows read tools and Bash, and ignores both permissions.yaml and command-line allow or exclude rules. Its other absolute mode, --auto, allows everything.
The IDE extension has a separate escape route. Continue's Plan documentation says built-in tools are restricted to read-only operations, but all MCP tools remain available because Continue does not filter them. The same page warns that some MCP tools can write to a system or external service.
So the label covers selected tools in Continue. It does not make the repository mount read-only, remove write-capable programs from the shell, disable network access, or narrow an API token.
Bash can cross the tool boundary
The agent sees a tool named Bash. The operating system sees a process running with a user identity, environment, filesystem mounts, installed programs, and network routes.
Removing a native Write tool does not block sed -i, an interpreter, a package installer, or a database client launched from the shell. A command used for inspection may also trigger project hooks or helper programs. Whether anything changes depends on the environment that executes the command.
Remote tools have the same problem in another form. MCP tool names and descriptions tell a model what it can request. The MCP specification says clients must treat tool annotations as untrusted unless they come from a trusted server. Its Tools guidance recommends confirmation for sensitive operations, visible inputs, validated results, timeouts, and usage logs.
None of those interface measures can revoke authority already granted to the MCP server or its token. A planning agent connected to a project-management server with permission to edit tickets can still reach a write operation if the client exposes it. A least-privilege agent setup has to restrict the credential and downstream service, not only the menu shown to the model.
Use canaries to test "read-only"
An isolated repository and disposable service account can reveal the actual boundary. Do not ask the model whether it thinks a write is forbidden. Attempt harmless state changes through every route and observe what the runtime blocks.
Try to create a file through the native Write tool, Bash, an interpreter launched by Bash, and any filesystem MCP server. Send a request to a controlled network endpoint. Give a test MCP account one disposable record, then check whether Plan mode can update it. Record the requested tool call and the downstream result.
Set the expected outcomes before running the test:
| Surface | Expected in planning | Enforcement point |
|---|---|---|
| Native file tools | Read only | Client tool filter |
| Bash | Inspection commands only | Sandbox or command allowlist |
| Local MCP | Read-only methods | MCP server and process permissions |
| Remote MCP | Read-only API scopes | OAuth token and service authorization |
| Network | Denied unless required | Container or host egress policy |
Any successful state change disproves the read-only claim for that deployment. The fix belongs at the point with authority. A precise tool interface makes calls easier to review, but a clear name cannot remove an operating-system permission.
Constrain unattended review below the model
For pull-request review or codebase analysis, mount the repository read-only inside an ephemeral workspace. Give the agent a separate writable directory for temporary files. Keep production credentials, SSH agents, package-registry tokens, cloud configuration, and browser sessions out of its environment.
If analysis requires Bash, run it in a container or sandbox with no repository writes and no network by default. A command allowlist can narrow the surface further, although interpreters and permissive flags can turn an apparently safe command into arbitrary execution.
MCP access should be split by purpose. A planning profile needs credentials that downstream services enforce as read-only. Hiding write tools in the client is insufficient when the server still accepts the request.
There is also a maintenance decision to make. Continue's official README says the project is no longer actively maintained and calls version 2.0.0 the final release. It says that release removed anonymous telemetry and authentication, along with bug fixes. The repository remains available under Apache-2.0, but teams still using it need to pin versions, mirror the source, and assign someone to review dependency, platform, and protocol changes.
Provider choice does not alter this permission model. A model called directly or through an OpenAI-compatible gateway such as ISH API inherits the same Bash process, filesystem mounts, and MCP credentials.
Define the failures you require
For Continue CLI, --readonly means built-in write tools are excluded while Bash remains. For Continue's IDE Plan mode, MCP tools sit outside the built-in filter. Both can be used safely when lower layers enforce the intended boundary.
Write the policy as testable failures: the repository cannot be modified, external records cannot be updated, and unapproved network requests cannot leave. Capture each blocked attempt in agent traces. If a canary write succeeds, the environment is writable, whatever the mode selector says.
