Zed v1.26.1-pre Released: Built-in Pyrefly, Debugger Variable Trees, and WASM Debugging

The Zed team has released the v1.26.1-pre pre-release, which merges 19 commits in total. The highlights center on three areas: bundling Pyrefly as an optional Python language server, adding expandable variable trees to debugger hover tooltips, and adding DWARF debugging to the JavaScript debugger to support WebAssembly source-level debugging. The AI Agent experience has also received multiple refinements.

AI Agent: Fine-Tuning Search and Thinking Controls

The model and configuration selectors for the Zed Agent and third-party ACP Agents now have more accurate fuzzy search, and the search preparation logic has been moved off the UI thread to avoid blocking the interface when there are many candidates (#64147). This change seems minor, but for users who frequently switch models throughout the day, the improvement in interaction smoothness is immediately noticeable.

On the compatibility front, this release fixes OpenCode's behavior when replaying DeepSeek^Ad reasoning and when disabling thinking for Google models (#65922). At the same time, thinking controls now include explanatory text: when thinking cannot be disabled at the selected effort level, the interface clearly tells the user why (#62480), reducing the confusion of "why doesn't the button do anything when I click it."

Debugger: Variable Trees and WebAssembly Debugging

The debugging experience is the centerpiece of this update. The JavaScript debugger now includes DWARF debugging support, allowing WebAssembly source code to be debugged directly (#65371). For developers using WASM outside the browser or in embedded environments, this fills a gap that previously existed in the debugging chain.

Hover tooltips now introduce an expandable, keyboard-accessible variable tree (#53198). Nested objects and arrays are no longer collapsed into a single hard-to-read string; instead, they can be expanded and inspected layer by layer, which is especially useful for troubleshooting deep data structure issues.

DWARF (Debugging With Attributed Record Formats) is a debugging information format widely used by compiled languages. It encodes the mapping between source line numbers, variable names, type layouts, and machine code addresses into binary files. WebAssembly itself only describes stack-based instructions and contains no source-level information; however, when compiling to wasm with Clang/LLVM's -g option, the toolchain additionally generates DWARF sections (usually embedded in custom .debug_* sections).

Zed's JavaScript debugger is based on the Chrome DevTools Protocol, and V8 can parse this DWARF data and map wasm instruction addresses back to the original C/C++/Rust source locations. As a result, breakpoints can be set on .rs or .c source files, and stepping follows the source code rather than disassembly. This is particularly useful for scenarios using wasm-pack, Emscripten, or WASI runtimes where you want to debug directly in the editor rather than relying on browser DevTools. Note that this capability depends on debug build artifacts retaining debug sections; release builds typically strip DWARF.

The expandable variable tree relies on the variablesReference mechanism in the Debug Adapter Protocol (DAP): when the debugger returns a variable list, it provides only a reference ID for structured values rather than the full content, and the client requests their child variables on demand. Zed's implementation calls the variables request in the hover popup and renders it hierarchically, while binding keyboard focus to each node so users can expand nested structures without leaving the keyboard. For deeply nested objects, long arrays, and containers such as Map/Set, this avoids the previous problem of fields being compressed into a single line by toString and becoming hard to locate—but it also means each expansion triggers a DAP round trip, so response speed should be kept in mind on high-latency remote debugging links.

Language Support: Pyrefly Becomes an Optional Built-in Python LSP

Pyrefly has been added to the built-in list as an optional Python language server, which users can enable in Python's language_servers setting (#44262). This means Zed's Python support is no longer limited to a single option; users can choose according to project size and type-checking needs.

In addition, the flow for stopping and restarting a language server via the LSP button has been improved (#65387); SQL syntax highlighting for sql! string literals in Rust has also been enhanced (#58778).

Pyrefly is a Python type checker and language server open-sourced by Meta in 2025, implemented in Rust, with the goal of providing checking speeds an order of magnitude faster than mypy and Pyright while supporting full type inference, generics, and the new PEP 695 syntax. It provides diagnostics, completions, go-to-definition, and other capabilities to editors via the LSP protocol, so it can be used directly as Python's language_server in Zed.

Zed's previously built-in Python options mainly relied on pyright or user-configured basedpyright, ruff, and others. Adding Pyrefly to the built-in list means users no longer need to manually write installation commands and binary paths; they can switch simply by specifying the name in language_servers. For large monorepos, Pyrefly's incremental checking architecture can significantly shorten initial indexing time; however, its type-checking rules are not entirely consistent with Pyright's, so migrating projects may require handling a batch of newly appearing diagnostics.

Remote Development and Other Improvements

The SSH reconnection logic has been adjusted to complete the handshake before starting the resync timeout, reducing the probability of false timeout judgments on weak networks (#65457). On macOS, Display P3 color space support has been added, which can be enabled via the use_display_p3 setting (#64394).

The project panel's project_panel.sort_order now includes an extension option, allowing files to be grouped by extension (#65776); fuzzy search ranking in the file finder has also been optimized (#59224).

Notable Bug Fixes

Several fixes in this release are directly related to data safety: when discarding unstaged changes in the Git panel, staged content is no longer discarded along with them (#65559); when removing a project from the sidebar and canceling the save prompt, it is no longer incorrectly removed from the recent projects list (#65683).

Agent-related fixes include: a freeze when restoring threads containing subagents (#65177), a crash caused by mentioning filenames containing newline characters (#65693), the authentication flow overwriting drafts (#65844), and duplicated thinking text when an OpenAI-compatible provider returns both reasoning and reasoning_content (#65926).

Other fixes cover error classification for invalid Google AI API keys (#65885), underline display for IME composition text in single-line input boxes (#65610), sorting of enum value completions in settings.json (#65589), Markdown preview tabs with the same name not showing a table of contents (#65736), failure when calling Mistral Large 4 through an OpenAI-compatible provider (#65915), and more.

Breaking Changes

ACP configuration defaults now apply only to new sessions; reopening an existing session preserves its original settings (#65850). Users who relied on default configuration overriding existing session behavior should take note of this change.

As a pre-release version, v1.26.1-pre is suitable for developers who want to try new features early; for production environments, it is recommended to wait for the official release.

ACP (Agent Client Protocol) is a communication protocol proposed by Zed between the editor and AI coding agents, defining messages for session creation, context injection, tool calls, and configuration negotiation. Zed acts as the client, and external agents such as OpenCode and Gemini CLI connect via ACP.

Previously, ACP agent configuration defaults (such as model and thinking effort level) were reapplied every time a session was opened, effectively overriding the user's manual adjustments from the previous session. This change makes defaults take effect only when creating a new session, while existing sessions resume with their persisted settings. This is consistent with the convention in most editors that "session state is independent of global defaults," but if users previously relied on defaults to uniformly reset agent behavior, they will need to explicitly modify the configuration or switch settings when creating a new session.