Read-only mode is no longer available in JetBrains ACP integration

I’m using codex-acp in PyCharm through the JetBrains ACP integration.

At the moment, the permission mode selector only shows:

Ask for approval
Approve for me
Full access

There is no Read-only option anymore.

I also checked the effective Codex sandbox mode from inside the session:

Ask for approval → workspace-write
Approve for me → workspace-write
Full access → danger-full-access

So currently there seems to be no way from the PyCharm UI to start Codex ACP in an actual read-only sandbox.

This is especially confusing because Ask for approval sounds like file modifications should require confirmation, but Codex can still edit files inside the workspace without asking, since the effective sandbox is workspace-write.

I’m not sure whether this is a bug/regression in codex-acp or in JetBrains/PyCharm’s ACP integration. I’m reporting it here first because different ACP agents expose different permission/mode controls in PyCharm, so it looks like these options may be provided by the ACP server itself.

Expected behavior: there should be a way to select a true read-only mode, where Codex can inspect the project but cannot modify workspace files without explicit user approval.

I’ll attach a screenshot of the current permission mode selector and an example of the observed behavior.

Could you clarify whether this behavior is expected on the codex-acp side, or whether it should be reported to JetBrains instead?

Also, is there currently any supported way to use codex-acp in a true read-only mode from JetBrains IDEs?

I'm using zed and am running into the same issue, so it must be independent of the editor.

I know it was there on Thursday and I am pretty sure that I did not update zed on the day that it disappeared. It is possible that Codex updated itself.

I'm using zed and an running into the same issue, so it must be independent of the editor.
I know it was there on Thursday and I am pretty sure that I did not update zed on the day that it disappeared. It is possible that Codex updated itself.

And for me, it started right after the ACP update... i think... Not pleasant. I had to download the ChatGPT app on Linux and use the Codex there. The premissions are fine there. So it’s not OpenAI that did something... Probably

upd - After a day, even in the app, it stopped asking for permission, and the status is always “workspace-write
.” This is f... up...

I asked ChatGPT to investigate why it stopped requesting permission before modifying files when running through ACP.

What changed

The behavior appears to originate from commit 50f69e5 / PR #430.

In src/AgentMode.ts, lines 35–49, the mode with the internal ID read-only, now displayed as Ask for approval, was changed from an actual read-only sandbox to workspaceWrite.

Before commit #430:

{
    type: "readOnly",
    networkAccess: false,
},
"read-only"

After commit #430:

{
    type: "workspaceWrite",
    writableRoots: [],
    networkAccess: false,
    excludeTmpdirEnvVar: false,
    excludeSlashTmp: false,
},
"workspace-write"

Because the effective policy is now workspaceWrite, file modifications inside the workspace no longer require permission.

Additionally, CodexAcpClient.sendPrompt(), lines 791–818 passes the selected ACP mode values explicitly on every turn:

approvalPolicy: agentMode.approvalPolicy,
approvalsReviewer: agentMode.approvalsReviewer,
sandboxPolicy: addAdditionalDirectoriesToSandboxPolicy(
    agentMode.sandboxPolicy,
    additionalDirectories,
),

Therefore, user configuration does not restore read-only behavior because the ACP mode supplies workspaceWrite directly for every prompt.

What we tried locally

For a diagnostic test, we modified the installed ACP bundle:

~/.cache/JetBrains/PyCharm2026.2/acp-agents/codex-acp/1.7.0/node_modules/@agentclientprotocol/codex-acp/dist/index.js

The relevant original code was around lines 27123–27138, with the default mode at line 27165.

We changed:

- type: "workspaceWrite"
+ type: "readOnly"

- "workspace-write"
+ "read-only"

- static DEFAULT_AGENT_MODE = _AgentMode.Agent;
+ static DEFAULT_AGENT_MODE = _AgentMode.ReadOnly;

The resulting block is around lines 27123–27134, with the new default at line 27162.

Changing the default mode was only done so that new diagnostic sessions would automatically use the modified mode. The permission behavior itself changed after replacing workspaceWrite with readOnly.

After restarting ACP and creating a new session, ChatGPT started requesting permission before modifying files inside the workspace.

The screenshot below shows the result after applying these local diagnostic changes.

Based on your research:

https://github.com/agentclientprotocol/codex-acp/pull/430/changes#diff-267cdc378896810f60ce135f2dd4a97239d5b5fd9254198140a3bdda360acea8R40-R52

My editor received the codex-acp update on august 27th which is the exact date version 1.7.0 was released and removed the read-only option from the dropdown.

I can't tell if someone removing the read-only mode means it is gone for good or whether that was a mistake and will be reverted, especially since we haven't heard anything from nikita-ashihmin.

@BountyHanter

Confirming from a non-IDE ACP client — this answers @BountyHanter's first question: the behaviour is in codex-acp, not in JetBrains or Zed.

Setup: codex-acp 1.10.0 + codex-cli 0.153.4, custom ACP client (a multi-agent orchestrator) that denies every session/request_permission. Counting the requests actually received:

mode	write target	`request_permission`	file written
`read-only`	`<cwd>/probe.txt`, via shell	0	✅
`read-only`	`<cwd>/probe.txt`, via `apply_patch` (cwd under `/tmp`, then under `$HOME`)	0	✅
`agent`	same	0	✅
`read-only`	file in a sibling dir of the cwd	1 (`kind: edit`, `locations`)	❌ denied, honoured

Two things this adds to @BountyHanter's excellent root-cause analysis of #430:

The mediation path itself is fine. The last row shows session/request_permission is emitted, well-formed, and the denial is honoured. It is simply unreachable for the workspace — so this is not a broken permission channel, it is a sandbox that pre-authorises the one directory that matters. (Note writableRoots: [] is not the lever it looks like: workspaceWrite grants the cwd by construction, so emptying the extra roots changes nothing here.)

There is no out-of-band workaround left. CODEX_CONFIG='{"approval_policy":"untrusted"}' now fails the session outright (no longer supported, codex 0.153); {"sandbox_mode":"read-only"} and {"default_permissions":":read-only"} are accepted but have no effect, since turn/start overrides thread config (#310). So reverting or re-exposing a genuine {type: "readOnly"} sandbox is currently the only path.

Why a non-IDE client cares. Our orchestrator enforces its own write policy (per-role file ownership) through the ACP permission hook. It cannot verify that hook would ever be consulted, so it refuses to spawn codex-acp at all — we lost an otherwise excellent agent over a sandbox default. Any mode where in-cwd edits reach the client would restore it.

I observe the same behavior on Emacs, using agent-shell.

@mgallet92i

Thanks @mgallet92i for confirming this with a non-IDE ACP client. This matches the behavior I have observed and the workaround I am currently applying locally.

Concrete minimal fix

The relevant preset is currently defined in src/AgentMode.ts, lines 38–53.

The ReadOnly mode currently advertises the ID read-only, but sends a workspaceWrite sandbox:

static readonly ReadOnly = new AgentMode(
    "read-only",
    "Ask for approval",
    "Always ask to edit external files and use the internet",
    "standard",
    "on-request",
    "user",
    {
        type: "workspaceWrite",
        writableRoots: [],
        networkAccess: false,
        excludeTmpdirEnvVar: false,
        excludeSlashTmp: false,
    },
    "workspace-write",
);

The minimal change that restores genuine read-only behavior is:

 static readonly ReadOnly = new AgentMode(
     "read-only",
     "Ask for approval",
-    "Always ask to edit external files and use the internet",
+    "Always ask before editing, writing, deleting files, or using the internet",
     "standard",
     "on-request",
     "user",
     {
-        type: "workspaceWrite",
-        writableRoots: [],
-        networkAccess: false,
-        excludeTmpdirEnvVar: false,
-        excludeSlashTmp: false,
+        type: "readOnly",
+        networkAccess: false,
     },
-    "workspace-write",
+    "read-only",
 );

After applying this change, modifications inside the workspace once again reach the ACP permission mechanism and require explicit approval.

If Ask for approval is intentionally supposed to retain workspaceWrite, then an additional genuine Read-only mode should be exposed instead. The important part is that at least one selectable mode must send:

{type: "readOnly", networkAccess: false}

At the moment, no advertised mode provides that behavior.

Local workaround after every update

JetBrains installs each codex-acp release into a separate versioned cache directory. I have therefore had to apply the same change manually to the generated dist/index.js after updates to:

1.7.0
1.8.0
1.10.0

After patching and restarting the ACP session, the expected permission prompt returns. The next automatic update installs a fresh unmodified package, so the workaround has to be applied again.

For my local setup, I also change [DEFAULT_AGENT_MODE](https://github.com/agentclientprotocol/codex-acp/blob/main/src/AgentMode.ts#L81):

-static DEFAULT_AGENT_MODE = AgentMode.Agent;
+static DEFAULT_AGENT_MODE = AgentMode.ReadOnly;

That final change is only my preferred default and is not required for the upstream fix. Restoring or adding a genuine selectable read-only mode is the essential part.

Refactor: Rename ReadOnly mode to EditInternal with clarified strings

Add: True read-only mode with read-only sandbox policy

The same thing, thanks to BountyHanter for workaround advice. And seems that in every new update - the issue persists.

build(deps): codex-acp 1.12.0 -> 2.2.2; edits tier runs in workspace-…

Navigation Menu

Repository navigation

Read-only mode is no longer available in JetBrains ACP integration #450

What changed

What we tried locally

Concrete minimal fix

Local workaround after every update

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Read-only mode is no longer available in JetBrains ACP integration #450

Description

Activity

BountyHanter commented on Aug 30, 2026

valentingoebel commented on Aug 30, 2026

BountyHanter commented on Aug 31, 2026

BountyHanter commented on Aug 31, 2026

What changed

What we tried locally

valentingoebel commented on Sep 1, 2026

mgallet92i commented on Sep 6, 2026

quazgar commented on Sep 7, 2026

BountyHanter commented on Sep 7, 2026

Concrete minimal fix

Local workaround after every update

prapeller commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions