Zed's AI switch defines a feature boundary
Zed’s global AI switch expresses a clear feature choice. Separate it from panel visibility, vendor approval and evidence about telemetry or network activity.
By 
Paul. AI and agentic engineering
An editor’s global AI switch is useful because it turns a scattered preference into an explicit feature decision. Its value depends on keeping that decision precise. Disabling AI features is different from hiding a panel, approving a particular model provider or proving that an editor makes no network connections. A team adopting the setting should state which of those outcomes it actually needs.
Zed announced disable_ai on 23 July 2025. The announcement said the setting reached Preview that day, with Stable expected the following week. It also described an onboarding switch as forthcoming. Those statements establish the launch sequence as announced, rather than proving the date every user received the option. Looking back from November 2026, the durable idea is a single declared choice about AI functionality.
The current settings reference, consulted on 8 November 2026, describes disable_ai as disabling all AI features and gives its default as false. That is current documentation, not a pinned inventory of the July implementation. This article relies on the dated announcement for the historical claim and the current reference for the documented setting today.
Visibility does not define permission
Closing an assistant panel changes what occupies the screen. A feature decision concerns whether the functionality is available. Those questions can overlap in the interface without becoming equivalent. If a team wants AI disabled, “the panel is no longer visible” is weaker evidence than an explicit setting whose documented purpose matches that requirement.
The same distinction matters when reviewing screenshots of an approved development environment. A clean workspace can show that distracting controls are hidden while saying little about settings behind them. Document the actual intended configuration in terms that another authorized developer can inspect. A screenshot may supplement that explanation, but it cannot replace it.
This does not mean every team needs a centrally managed editor. A small group may reasonably maintain a short setup note and check the relevant option after installation. The amount of control should follow the obligation. An individual preference and an enforceable organizational restriction require different evidence, even when both begin with the same switch.
Vendor approval is another decision
Zed’s July announcement recognizes several reasons people may decline AI, including personal preference and organizational restrictions. It also discusses bringing provider keys or using local models as alternatives for some privacy concerns. These are options described by the vendor, not proof that a particular organization’s requirements are met.
A rule permitting one provider does not necessarily permit every AI feature that an editor can expose. Conversely, a rule declining AI assistance may apply regardless of where a model runs. The team should describe the permitted activity before selecting the tool configuration. Otherwise a conversation about one concern can accidentally authorize something broader.
Keep the explanation concrete. Identify whether the requirement concerns code sent outside the machine, a particular contractual relationship or any model-generated assistance during the task. These are possible requirements to clarify, not policies attributed to an AL+ client. The source establishes that Zed offers a choice; it cannot decide the reader’s obligations.
An AI switch is not a network audit
Nothing in the meaning of “disable AI features” establishes zero telemetry or zero network traffic from the whole editor. Updates, extensions and other connected functions need their own examination if the requirement concerns network behavior. That is a logical limit on the claim, not a finding that this setting leaks data.
Likewise, a promise about prompt retention is narrower than a statement about every category of data a product might process. Avoid collapsing those claims into a reassuring sentence about privacy. If the decision requires knowing what leaves a machine, use evidence about the relevant version, configuration and activities, together with applicable documentation and agreements.
This article reports no traffic capture, installation test or client assessment. It therefore makes no claim about observed connections with the setting enabled. The useful recommendation is to match the evidence to the assertion: settings documentation for feature intent, version-specific checks for operation, and separate network evidence when network behavior is the question.
Configuration has a lifecycle
A configuration decision needs to survive ordinary maintenance. Record the setting and the version against which it was assessed. After a relevant update, review changed documentation and verify the behavior that matters to the team. Current documentation may describe features that did not exist when the original decision was made.
The check can remain focused. If the requirement is simply to remove AI assistance from an individual’s editing workflow, inspecting the supported setting and relevant entry points may be enough. If the requirement is a stronger organizational control, determine what can override it and who may change it. Do not infer enforcement merely from the presence of a user preference.
Also keep the reason understandable. A developer replacing a machine should be able to tell whether the option represents personal comfort or a condition of the work. That context prevents a well-intentioned setup change from silently reopening a decision another person still depends on.
Leaving AI available can be reasonable
The strongest counterargument is a team with an approved provider and a useful, understood AI workflow. Globally disabling everything could remove a legitimate tool and create avoidable configuration exceptions. A narrower arrangement may serve that team better. The July announcement’s choice does not imply that disabling is universally preferable.
For custom software development, agree on the permitted assistance and the evidence needed to support it. Use the global switch when its feature boundary matches the requirement. Keep visibility, provider decisions and network assertions separate. A clear off-switch improves choice most when nobody asks it to prove more than it says.