ACP: external agents have no way to read project diagnostics (incl. LSP-only warnings like Tailwind) #58546
ap-justin
started this conversation in
Feature Requests
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
External agents running over ACP (Claude Code via
claude-code-acp, Gemini CLI, Codex, etc.) cannot programmatically read Zed's project diagnostics. The user can manually inject them through the@diagnosticsmention in the agent input, but the agent itself has no tool/method to query them between turns.This forces external agents to re-derive diagnostics from the CLI (
tsc --noEmit,eslint,biome check, etc.), which works for compiler/linter output but misses LSP-only warnings — most painfully@tailwindcss/language-server(invalid classes, deprecated arbitrary values likez-[51]→z-51), CSS LSP, and any language server without an equivalent headless CLI.Zed's native agent already has access via the internal
diagnostics_tool(crates/agent/src/tools/diagnostics_tool.rs). External ACP agents have no equivalent.Why this matters
The agent-iteration loop is "make a change → check diagnostics → fix → repeat." Without programmatic diagnostics access, that loop breaks for any warning class that lives only in an LSP. Today the workarounds are:
Proposal
Expose project diagnostics to ACP agents via either:
session/diagnosticsorfs/diagnostics) that returns current diagnostics, optionally filtered by file/severity/source.textDocument/publishDiagnosticsworks on the LSP side.Either route reuses Zed's existing aggregated diagnostics buffer — the same source
@diagnosticsand the nativediagnostics_toolalready consume.Related
Environment
Zed v1.5.x stable, Claude Code via
@zed-industries/claude-code-acp.All reactions