The integration doesn't honor `claude/settings.json` permissions for file reads.

[antran22]

The last experiment with Claude Code integration in Zed sent my .env to Anthropic server, even though I have had .claude/settings.json file with proper deny rules:

{
    "permissions": {
        "deny": ["Read(/.env)"]
    }
}

Yet if I ask the Claude Code integration to read & print the .env file out, it will gladly do it:

In contrast, Claude Code in the terminal works just fine

The problem comes from the fact that the ACP adapter mock out tool calls such as Read, Write into ACP specific function calls that read directly from Zed's buffer, instead of reading through the Claude Code filesystem access

claude-code-acp/src/acp-agent.ts

Line 403 in 75b44e9

async readTextFile(params: ReadTextFileRequest): Promise<ReadTextFileResponse> {

May I ask if there is any plan from the Zed Editor & Claude ACP teams to work on this design problem?

[benbrandt]

@antran22 thanks for reporting, this is indeed a challenge with the current approach. We'll take a look and see what we can do

[antran22]

One suggestion would be to use .ignore file and let the client (Zed editor) decide to whether let the agent read it or not.

I had read through the specification of ACP and I think that this should be something baked in the protocol. For now the protocol specification doesn't mention anything about managing read/write permission to files.

[gsabran]

Why not let CC run its own read/write/bash tool calls, while still managing permissions and session updates?

I was not exactly sure if it this was an implementation decision made for the CC ACP adapter, or coming from the protocol itself.

The teams building each of those agents (CC, Codex etc) are probably baking a lot of expectations on how those core tool should work for them (like visible in this current issue) and fine tuning things like tool output format so that they work well with their models and agent pipelines. It doesn't seem desirable to have the ACP Client take over the execution of those tools.

What if instead things were done like:

Claude Code		ACP Client
tool input: Read(file: ...)	→	buffer request until request permission received
request permission (over MCP for CC)	→	handle permission
continue tool execution	←	accept / reject tool call
tool output: Read...	→	update tool call status

ie the ACP client doesn't execute the tool call, but it handles permissions, and updates the session state.