Zed’s Agent Skills Push Makes the Editor a Supply-Chain Surface

Zed’s 1.5.0-pre release looks, at first glance, like normal editor evolution: better Mermaid rendering, thread renaming, smoother panels, clickable paths, faster OpenAI service tiers, and the usual bug-fix parade. The more important story is tucked inside the Agent section. Zed is turning skills, AGENTS.md rules, MCP/OAuth behavior, pending tool permissions, and external ACP access into editor-managed surfaces.

That is powerful because the editor is where developers already make trust decisions. It is also risky for the same reason. A terminal agent can ask for permission in a scrollback buffer. An editor can show the file, the diff, the tool call, the project rule, and the imported skill in one workspace. If Zed gets this right, agent behavior becomes more visible and easier to govern. If teams treat skills as harmless Markdown pasted from the internet, they are going to recreate the package-supply-chain problem with fewer checks and more authority.

Skills are dependencies wearing Markdown

The headline agent feature in Zed 1.5.0-pre is support for importing skills from GitHub Markdown URLs in the Skill Creator. The release notes say the Skill Creator can import from GitHub Markdown URLs; the linked PR adds URL mode, clipboard prefill, a command-palette entry, and frontmatter parsing so imported skills can prefill metadata and content.

The happy path is obvious. A team can publish reusable agent behavior as Markdown, import it quickly, preserve metadata, and avoid hand-copying the same prompts into every environment. For organizations trying to standardize code review expectations, migration playbooks, test-writing style, or framework-specific agent behavior, that is useful. Good skills can become shared engineering muscle memory.

The risky path is just as obvious. Markdown feels inert until it becomes operational guidance for an agent with access to files, tools, MCP servers, and perhaps multiple working directories. A skill can encode assumptions about commands to run, files to inspect, conventions to override, or tools to trust. It may not be “executable” in the shell-script sense, but it can still steer execution. That is enough to make provenance matter.

The right mental model is dependency management. Prefer known internal catalogs. Pin GitHub references where possible instead of importing from a moving branch. Review frontmatter. Track who owns a skill. Keep project skills in repositories where pull requests can review them. Avoid importing behavior from arbitrary repos during a live coding session. The fact that the file extension is .md should not lower the bar; it should remind everyone that the new supply chain is partly made of instructions.

Global skills need local skepticism

Zed also adds support for copying or moving skills into and out of ~/.agents/skills and deleting individual skills, with explicit confirmation prompts for each operation. The release-linked work rejects moving the global skills root itself and requires confirmation for operations that delete or move skill resources.

Those confirmations are not merely UX polish. Global skills are behavior that can apply across projects. Deleting, moving, or importing them changes the agent’s operating environment. Treating those actions as review moments is the right instinct.

But confirmations are only the last line of defense. Teams should still decide whether global skills are allowed on shared machines, regulated workstations, build hosts, and support environments. Personal global rules can be useful for convenience — preferred test commands, naming conventions, documentation style — but they should not silently override project architecture policy. If a repo depends on specific agent behavior, that behavior belongs in the project, not in a developer’s home directory.

This is where Zed’s new command-palette actions for opening global and project-specific AGENTS.md rules matter. They make the instruction layers inspectable. That is the bare minimum for trust. Hidden policy is operational debt. If an agent makes a surprising edit because global instructions pushed it there, the developer needs an obvious way to inspect and correct the rule source.

Permission prompts are safety features, not interruptions

One of the smaller release notes is also one of the most important: Zed improved visibility of pending tool-call confirmations when they are scrolled out of view in the Agent Panel. The implementation adds a floating row when a pending permission prompt is offscreen, reusing the same allow/deny choice and raw input view, with a way to scroll back to the inline prompt.

That is the kind of UI detail that separates agent tooling from demos. Agent sessions often appear “stuck” because a permission prompt is waiting below the viewport. A user who cannot see the blocked operation may cancel the run, approve later without context, or assume the model failed. Keeping the prompt visible makes permission a live review step rather than scroll archaeology.

The raw input view matters too. Developers should not approve a tool call by vibes. They should inspect the command, file path, MCP operation, or requested access. This is especially true now that Zed is expanding agent access surfaces: external ACP agents can access all working directories in a project if they support it, and ACP now has a logout flow for agents that support it. “All working directories in a project” can be exactly what a multi-repo workspace needs. It can also be broader than a developer realizes if the editor has several checkouts open.

The practitioner rule is simple: define what a Zed “project” is allowed to contain before granting broad external-agent access. Do not keep secret-adjacent scratch repos, customer checkouts, or unrelated worktrees open in the same project if an external agent is allowed to see the whole set. The editor’s convenience boundary can become the agent’s authority boundary.

MCP and OAuth are no longer side quests

The 1.5.0-pre release sits on top of a nearby stable release, Zed 1.4.2, that added first-class skills, global AGENTS.md, image output from MCP tools, OAuth client pre-registration for the built-in MCP client, and fixes for MCP OAuth metadata and client-registration failures. That context matters because skills and MCP are converging into the same problem: how much authority does the editor-mediated agent have, and can the user understand it?

Once Zed is an MCP client, OAuth quality is not plumbing trivia. Remote MCP servers may touch issue trackers, docs, observability systems, internal APIs, design assets, or cloud resources. OAuth client pre-registration with explicit client ID and secret handling is the difference between an integration that belongs in an enterprise workflow and one that encourages users to paste credentials into whatever setup path happens to work.

Image output from MCP tools also widens the data surface. Screenshots, diagrams, UI states, trace captures, and visual artifacts can now appear as tool outputs and restored thread context. That is useful for debugging and design work, but it also means teams need to think about retention, redaction, and who can see restored agent threads. “The agent only reads code” is no longer a safe assumption once tool outputs become richer.

The numbers say this is not niche plumbing

Zed 1.5.0-pre was published on GitHub at May 27, 2026, 20:12 UTC. At research time the repository had roughly 172,139 stars, 13,417 forks, and 2,118 open issues. That size matters because these agent features are not landing in a fringe tool for hobby experiments. They are landing in a serious editor with a large developer audience.

The broader release also includes agent-adjacent quality-of-life changes: line-number gutters in read_file output, smoother expansion of large file outlines, clickable backticked file paths in the Agent Panel, automatic refreshes for the Zed-hosted model list, thread renaming, and Fast Mode priority-service-tier support for OpenAI models through both ChatGPT subscription and OpenAI API providers. These are not governance controls, but they support reviewability. If an agent cites a file, the user needs line numbers. If it references a path, the path should open. If a thread represents work, it should have a meaningful name.

That is the editor advantage. Zed can make agent work feel like part of the development environment instead of a separate conversation taped to the side. The risk is that integration can make authority feel natural before policy catches up.

For builders, the checklist is direct. Treat imported skills like dependencies. Keep project AGENTS.md under code review. Audit ~/.agents/skills periodically. Do not let personal global instructions become invisible team policy. Inspect pending tool-call input before approving. Use MCP OAuth with explicit client registration where available. Be careful when enabling external ACP agents across all working directories. And build an internal skill catalog before every developer starts importing “helpful” Markdown from search results.

My take: Zed is adding the right surfaces, but the release should make teams more cautious, not less. Skills are useful because they make agent behavior reusable. They are risky for exactly the same reason. The editor is becoming an agent runtime, and runtimes need provenance, permission, review, and revocation. Otherwise the next supply-chain incident will not arrive as a package install. It will arrive as a friendly Markdown skill that looked harmless enough to import.

Sources: GitHub — Zed v1.5.0-pre, PR #57458, PR #57760, PR #57632, Zed v1.4.2