Self-hosted infrastructure for a fleet of long-lived AI agents. Each agent runs in its own sandboxed container with a persistent workspace, internet access, and a pluggable driver.

Yes. Single-VM deploy on plain Docker with your own keys and data. No vendor lock-in, no per-seat SaaS tax, nothing leaves your stack.

Which agent engines (drivers) are supported?

One identical API across swappable brains: Vanilla, Opencode, Codex, and Claude Code. The driver is part of an agent's config and can be swapped anytime.

How do you keep my data and agents secure?

Every agent runs in a hardened container: read-only root filesystem, dropped capabilities, network egress filtering, and CPU/memory limits. LLM keys are stored server-side, encrypted, and never sent to the browser.

Can I watch what an agent is doing?

Yes. Every task streams over Server-Sent Events (assistant messages, tool calls, results, file changes, a live token meter), and reconnects resume where they left off.

Accounts are provisioned by admins; you self-host the stack. Use Get started, or sign in if you already have an account.

Claude Code LSP Setup for Production Repositories

The useful version of Claude Code LSP setup is not "turn on code intelligence and trust it." For a production repo, it is a small platform rollout: install the right language server, standardize the plugin, verify semantic lookup, watch diagnostics quality, and keep the build or typecheck command as the final source of truth.

The reader this matters for is the staff or platform engineer who has watched an agent grep through a monorepo, open six files, miss the real reference, edit the wrong helper, then spend another turn fixing type errors it could have seen earlier. LSP helps with that. It gives Claude semantic tools for definitions, references, hover/type info, implementations, call hierarchy, and diagnostics after edits.

It also introduces a new failure mode: if the language server is pointed at the wrong workspace, missing dependencies, stale generated declarations, or bad monorepo config, Claude may chase phantom errors with great confidence.

Use LSP when the question is about identity

Grep answers "where does this text appear?" LSP answers a different question: "which symbol is this, and where is that symbol used?" That distinction is the whole reason to add code intelligence.

Use Claude Code LSP for work like this:

Renaming or changing a typed API used across several packages.
Finding real references to a symbol before a refactor.
Checking hover/type information before editing a generic or overloaded function.
Jumping to implementation instead of scanning interface files.
Seeing type or syntax diagnostics immediately after an edit.

Keep grep for text-shaped work: config keys, docs, generated assets, string constants, framework conventions, unsupported file types, and places where the language server does not understand the project.

Scott Spence's SvelteKit report is a good field example. LSP found the exact get_posts definition where grep returned three ambiguous matches. But his usage sample still showed only 12 LSP calls out of 1,082 navigation calls over four days, partly because the TypeScript plugin did not cover .svelte files. The lesson is not that LSP failed. The lesson is that setup and coverage decide whether Claude actually gets semantic help.

The official Claude Code LSP setup path

Claude Code's official marketplace now includes code intelligence plugins. The plugin configures Claude's LSP connection, but the actual language server binary still has to exist on the developer machine and be available on PATH.

A practical rollout has four steps:

Install the language server binary for the repo language.
Install the matching Claude Code code intelligence plugin.
Restart Claude Code or reload plugins.
Verify with one known definition lookup and one intentional diagnostic.

The official plugin and binary pairs include TypeScript with typescript-language-server, Python with pyright-langserver, Go with gopls, Rust with rust-analyzer, C/C++ with clangd, Java with jdtls, C# with csharp-ls, and Swift with sourcekit-lsp.

For one developer, a user-scoped install is enough. For a team, commit the expectation in project settings with enabledPlugins or install with project scope. That standardizes the plugin name, but it does not install the binary for every engineer. Your bootstrap script still needs to check typescript-language-server --version, pyright-langserver --version, gopls version, or the equivalent for your stack.

Team rollout checklist

Treat this like developer tooling, not a personal preference. A team-ready Claude Code LSP setup should answer these questions:

Binary: which language server version is expected, and how is it installed?
Scope: is the plugin user-scoped, local to the project, or enabled through checked-in project settings?
Trust: who approves marketplaces and external plugins?
Workspace root: should Claude start at repo root or package root?
Memory: which servers need resource limits or narrower workspaces?
Verification: which command proves the language server is not lying?
Fallback: when should Claude ignore diagnostics and run the real build/typecheck?

That last item is the one teams tend to skip. LSP diagnostics are editor-facing and incremental. They are useful during the edit loop. They do not replace tsc -b, nx typecheck, cargo check, go test ./..., or the CI job that will actually block merge.

Monorepos need root decisions, not hope

Monorepos are where LSP gets valuable and where it gets brittle. Claude Code's startup directory controls file access, loaded instruction files, and project settings. Language servers also infer a lot from the workspace root.

Starting Claude at repo root gives broad context. It can also increase context noise and make language servers parse more than the task needs. Starting in a package narrows Claude's view, but the language server may need root-level project references, a go.work, shared TypeScript config, generated declarations, or Python execution environments.

In practice, document the root choice per repo:

Repo shape	Good default	What to verify
TypeScript project references	Repo root or package root with references loaded	`tsc -b` agrees with LSP diagnostics
Python services in one repo	Service root with Pyright execution environments	Imports resolve without fake unresolved-package errors
Rust workspace	Workspace root for shared cargo metadata	`cargo check` shape matches rust-analyzer settings
Go multi-module repo	Root with repo-standard `go.work`, or module root	`gopls` sees the intended modules

If the team uses --add-dir, additionalDirectories, Read deny rules, or claudeMdExcludes, document those with the LSP setup. Context scoping and language-server scoping should not fight each other.

The diagnostic trap

Diagnostics are the part that feels most magical. Claude edits a file, the language server reports an error, and the agent fixes it in the same session. That can save real review time.

But stale diagnostics are not theoretical. Anthropic issue #64239 describes a Windows, Nx, pnpm, TypeScript project-reference workspace where tsc -b and nx typecheck were correct while Claude Code's TypeScript LSP diagnostics stayed stale. The agent then reasoned about errors that were already fixed and sometimes reverted correct code.

Platform teams need a rule for this. A simple one works:

If LSP diagnostics match the authoritative typecheck, let Claude use them for fast repair.
If diagnostics are stale twice in one session, stop trusting them for that task.
If LSP and build disagree, the build wins.
If the disagreement repeats, disable the plugin for that repo until workspace config is fixed.

False positives also show up when internal monorepo packages are unresolved. Anthropic's troubleshooting docs call this out directly. Pyright maintainer guidance gives the same shape: if Pyright runs from repo root without root config, it uses defaults. In a Python monorepo, that can mean import errors that are configuration errors, not product bugs.

When MCP or IDE diagnostics are better

Native code intelligence plugins should be the default path when the language is supported. There are still cases where another route makes sense.

If your team already standardizes on VS Code, Claude Code's extension exposes a hidden local IDE MCP server. The model-visible diagnostics tool reads from the editor Problems panel. That lets Claude benefit from the same editor LSP setup developers already use.

For unsupported languages or headless environments, a generic MCP language-server bridge can expose diagnostics, definitions, references, hover, and rename. Some teams use hook-triggered diagnostic daemons for the same reason: the agent edits, the hook runs a fast semantic check, and the result is fed back before a full build.

Those alternatives add ownership. A custom bridge or plugin needs security review, versioning, logging, and a fallback story. Use them when official plugins do not cover the repo, not because custom tooling sounds cleaner on a diagram.

A practical operating model

For supported typed languages, turn LSP on by default in production repos where refactors and type safety matter. Then make it boring:

Pin or document language server installation.
Enable the official plugin through project settings where appropriate.
Verify semantic navigation with known symbols during setup.
Document monorepo root choices in CLAUDE.md or the team agent guide.
Keep authoritative typecheck commands in the same instructions.
Track repeated false positives and stale diagnostics as tooling bugs, not agent judgment problems.

The payoff is not that Claude stops using grep. It will still search. The payoff is that, when the task depends on semantic identity, Claude can ask the codebase a sharper question. In real codebases, that is often the difference between a small refactor and a wandering session with a green-looking but wrong diff.