In this article
A Zed profile controls which tools are available; tool permissions decide whether a call is allowed, denied or confirmed. External agents may own their configuration.
A Zed Agent Profile describes the tools available in a native agent thread and can set a default model. Tool Permissions describe how proposed calls are handled. Keeping the two layers separate explains why an enabled tool can still ask for approval and why an approval rule cannot make an unavailable tool appear in a profile.
Inspect the active native profile
The Agent Profiles guide describes Write, Ask and Minimal presets. They represent different intended tool availability. A customized profile can differ from the built-in description, so inspect its actual selection rather than relying only on a familiar label.
Open the Agent Panel profile selector and Configure, or use agent: manage profiles. Review the default model, built-in tools and MCP choices. A project-question workflow may need reading capabilities while a narrowly framed conversation may need no project tools at all.
Read approval policy independently
The Tool Permissions guide describes allow, deny and confirmation behavior. It also distinguishes the current agent.tool_permissions.default setting from the older agent.always_allow_tool_actions configuration. Use the reference matching the installed release.
Think of availability and permission as separate checks. A terminal tool omitted from the profile is not made available by a permissive terminal rule. A terminal tool enabled in the profile can still require review for its proposed command. This distinction prevents changing the wrong setting after an unexpected prompt.
Test a narrow workflow
Create a small disposable repository with a source file and a test description. First ask the agent to explain the function. Then request a proposed change. Observe which tools it offers, which calls prompt and what appears in the final diff.
Record a tool that is intentionally absent as well as one requiring confirmation. The absence test should inspect the profile’s actual tool set, not merely a model response saying it will avoid the tool. The confirmation test should inspect the proposed operation before permitting any change.
Identify an external agent before editing native settings
The External Agents guide explains that an ACP agent usually owns its runtime, model selection, authentication and tools. Zed can host the thread while another agent controls those capabilities. Native-profile assumptions therefore should not be automatically applied to every thread in the same panel.
Check the active agent identity when a setting seems ineffective. If the task runs through an external agent, locate its documented configuration and permission boundary. Editing a native default model does not establish that the external process will use that model for its next request.
Keep a reproducible profile decision
Record the profile configuration and approval policy separately alongside the editor release. Keep a sample task whose required capabilities are obvious to a reader. Repeat that task after a deliberate profile change and inspect both tool availability and request handling.
Profiles help make a workflow understandable, but the complete execution boundary includes the running agent and environment. A name such as Ask is not a substitute for inspecting the actual tool set, and an approval default is not evidence that a model can reach a file or external service that was never made available.
Related reading
Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.