Connect your client

Review the seven clients named in the setup registry and verify the active configuration and project root.

Signalint’s setup registry recognizes Claude Code, Cursor, Codex CLI, Antigravity, VS Code, Windsurf, and Zed. Its snippets launch signalint-mcp over stdio. Signalint itself requires no hosted endpoint or API key; model/provider requirements belong to the client.

Choose a setup guide

Project paths below are relative to the repository root. User paths describe the locations recognized by Signalint’s client registry, not a guarantee that every client version supports identical settings.

Client	Registry project target	User setup / registry target	Container key
Claude Code	`.mcp.json`	`~/.claude.json`	`mcpServers`
Cursor	`.cursor/mcp.json`	`~/.cursor/mcp.json`	`mcpServers`
Codex CLI	`.codex/config.toml`	`~/.codex/config.toml`	`mcp_servers`
Antigravity	`.agents/mcp_config.json`	`~/.gemini/config/mcp_config.json`	`mcpServers`
VS Code	`.vscode/mcp.json`	`Not emitted by v1 registry`	`servers`
Windsurf	`User scope only`	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`
Zed	`User scope only`	`~/.config/zed/settings.json`	`context_servers`

Recommended setup

Install Signalint in the repository you want to check.
Run npx signalint-mcp init there.
Choose a detected client and confirm the configuration write, or copy the printed snippet.
Restart or reconnect the MCP client.
Call ping and confirm structuredContent.projectRoot before the first check.

init orders detected project candidates before user candidates and asks before writing a selected client entry in an interactive run. Non-interactive runs print snippets rather than updating a client file. Configuration and .gitignore writes are separate setup effects.

Payload-mode choice

Use the default both mode while connecting and verifying ping’s structured project root. text mode omits that ping object; structured mode requires the host to expose structured diagnostic data to the model. Registry-generated snippets are not proof of support for every mode/editor version. Read MCP payload modes before opting in.

What the registry does and does not prove

The registry is authoritative for Signalint’s generated targets and shapes, not an external editor’s compatibility contract. A marker such as .cursor, .agents, or GEMINI.md is a detection hint, not proof that a client is installed or consumes the emitted path. Check your client’s active MCP settings and trusted-workspace requirements.

JSON merging uses strict JSON, not JSONC. Comments/trailing commas can fail; formatting is rewritten.
Other server entries are retained in parseable JSON, but the selected signalint entry is replaced, including custom env or arguments.
Codex block replacement is textual, not a complete TOML parser.
Back up settings before accepting a write, and verify ping afterward.
Antigravity paths marked “legacy” by Signalint are not automatically proven obsolete for your installed editor.

Canonical emitter: src/clients/registry.ts and src/init.ts.

Project scope or user scope?

Project scope is the safest place for repository-specific configuration. Claude Code, Cursor, and Codex entries can include a project cwd. Signalint’s registry does not emit cwd for Antigravity or VS Code; verify their inherited root after connecting.

User scope is shared. Windsurf and Zed use user-scoped locations in the registry. Shared targets outside the project normally omit a fixed repository cwd, which avoids silently checking the same old repository in every workspace—but the client still needs to launch the process in the correct place. The emitter uses path containment, so an unusual user target inside the project can still receive cwd; inspect the result.

Windows and runtime paths

Windows examples use cmd /c npx --no-install signalint-mcp to handle npm shims. Ensure the client sees Node.js ≥ 22.12.0, and that --no-install can find the project-local package.

If the package cannot be resolved or a linked shim fails, see troubleshooting. Then continue with the quickstart.