# Zed native or ACP agent: which settings apply?

Find the owner of Zed AI settings by distinguishing its native Agent, external ACP processes, forwarded MCP tools, and agent-native configuration.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/zed-native-vs-acp-settings-owner/
Language: en

In Zed, the native Agent and an external ACP agent can appear in the same panel while using different model and tool settings. Identify the selected agent path before changing provider configuration or approval rules.

## The concrete application boundary

Zed hosts external-agent threads through the Agent Client Protocol, but the external process usually owns its runtime, authentication, model choice, tools, and native configuration. Native Zed Agent profiles do not automatically apply to that process. Zed-configured MCP servers may be forwarded over ACP, while an agent may also read its own MCP configuration. Tool permissions therefore have more than one possible boundary: Zed’s forwarding controls and the agent’s own actions. Do not simplify this into an assertion that external agents ignore all Zed settings. Inspect the specific integration and the actual tool being invoked. A terminal-backed thread is another distinct path, not merely a renamed native Agent ([Zed Agent documentation](https://zed.dev/docs/ai/zed-agent)).

## A practical route

Open the Agent Panel and inspect the agent selector for the current thread. For the native Zed Agent, use Zed’s own model access and tool settings. For an external agent, open Agent Settings with agent: open settings and inspect External Agents; configured entries belong under agent_servers when native settings are needed. Use the external agent’s documented configuration for its provider and model. If an MCP tool is missing, inspect both Zed’s configured server and the agent-native MCP setup. Use dev: open acp logs to inspect the actual exchange when diagnosing the integration ([Zed External Agents](https://zed.dev/docs/ai/external-agents)).

## A worked example

A developer configures a local model for the native Zed Agent, then opens an external OpenCode thread and expects the same provider selection. OpenCode owns its model selection in that external path. Correct its native provider configuration rather than changing the already working Zed provider. Repeat a read-only explanation of a fictional helper and inspect which agent thread produced it.

| Check | Record |
| --- | --- |
| Thread owner | Native Zed Agent, external ACP agent, or terminal-backed thread. |
| Model owner | Zed provider settings or the external process’s native model configuration. |
| Tool owner | Zed forwarding controls and any agent-native tool configuration involved in the action. |

## Reading the failure correctly

A working native chat does not validate the external process’s credentials or installed executable. An absent external tool is also not proof that Zed lost its own MCP connection. Preserve the thread identity and relevant ACP observation before changing settings, otherwise one correction can silently switch the task to another agent path ([Zed Tool Permissions](https://zed.dev/docs/ai/tool-permissions)).

## What completes the check

The useful result is an ownership map for model selection, instructions, MCP, and approvals. The shared panel is a presentation surface; it does not merge every agent’s configuration into one universal Zed profile.

Related background: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/), [Coding LLMs on 12GB VRAM: Budget Context and Headroom](/journal/coding-llm-12gb-vram/).