Related Pages

Related topics: Core Agent & Tool System, Language Server Backend (solidlsp), Configuration, Deployment & Operations

Overview & System Architecture

Purpose and Scope

Serena is a coding agent toolkit that exposes semantic code intelligence to large language models through the Model Context Protocol (MCP). It wraps Language Server Protocol (LSP) backends for many programming languages and provides a curated set of MCP tools that allow agents to navigate, search, and edit source code at the symbol level rather than at the raw text level.

The system targets two primary use cases:

1. Coding assistants and agents that need precise code understanding, refactoring, and cross-file editing capabilities.
2. Developer integrations (e.g., JetBrains plugin, Copilot CLI) that want a token-efficient alternative to file-based context.

Serena is delivered as an MCP server that can run over stdio or sse transports and is typically configured per-project so that the active language servers match the languages present in the codebase.

Architecture Layers

Serena's architecture is composed of four cooperating layers, from the agent-facing surface down to the language servers:

flowchart TB
    Client["MCP Client<br/>(Claude Code, Copilot CLI, JetBrains)"]
    Mcp["MCP Server Layer<br/>src/serena/mcp.py"]
    Agent["SerenaAgent<br/>src/serena/agent.py"]
    Project["Project / LSManager<br/>src/serena/project.py, ls_manager.py"]
    Lsp["SolidLSP Protocol Handler<br/>src/solidlsp/lsp_protocol_handler/"]
    Ls["Language Servers<br/>(jedi, tsserver, rust-analyzer, ...)"]

    Client -- "JSON-RPC (tools/list, tools/call)" --> Mcp
    Mcp --> Agent
    Agent --> Project
    Project --> Lsp
    Lsp -- "LSP over stdio<br/>JSON-RPC 2.0" --> Ls

The agent layer is the central orchestrator. It is instantiated when a client session starts, composes a system prompt from project context, and dispatches tool calls to the appropriate language server through the project manager.

SolidLSP Protocol Handler

The lowest layer, SolidLSP, is a self-contained LSP client implementation that Serena uses to talk to language servers. It is split across four modules:

• lsp_types.py — Python TypedDict and Enum definitions mirroring the LSP v3.17.0 specification, including capabilities, requests, semantic tokens, and completion kinds. These are code-generated and marked "DO NOT EDIT" at the top of the file. Source: src/solidlsp/lsp_protocol_handler/lsp_types.py:1-5
• lsp_requests.py — High-level request methods (e.g., textDocument/definition, textDocument/references, textDocument/documentSymbol, textDocument/typeDefinition, textDocument/documentColor) that wrap the JSON-RPC primitives. Source: src/solidlsp/lsp_protocol_handler/lsp_requests.py
• lsp_constants.py — String constants for JSON-RPC keys (URI, RANGE, POSITION, LINE, TEXT_DOCUMENT, etc.) used when building messages. Source: src/solidlsp/lsp_protocol_handler/lsp_constants.py
• server.py — JSON-RPC 2.0 message construction (make_request, make_notification), parameter handling for Void-type methods, and Content-Length header framing for stdio transport. Source: src/solidlsp/lsp_protocol_handler/server.py

A notable compatibility detail lives in _build_params_field: methods typed as Void (such as shutdown and exit) must omit the params field entirely to satisfy servers like HLS and rust-analyzer, while other methods send {} for None parameters to remain compatible with Delphi/FPC LSP servers. Source: src/solidlsp/lsp_protocol_handler/server.py

Multi-Language Support and Known Failure Modes

Serena is designed to host multiple language servers in a single project. The LSManager is responsible for spawning the appropriate server per language and isolating their processes. Multi-language support is a frequent topic in community discussions: issues #611 and #192 track the unfinished MultiLanguageLS work, where conflicts around process isolation have repeatedly blocked completion. Source: issue #611, issue #192

Several known failure modes are visible in the public issue tracker and are useful when reading this architecture:

• TypeScript references return zero results while definitions still work, because tsserver loads files as inferred projects instead of the project's real tsconfig.json. Source: issue #1586
• Julia language server in the project's languages: list causes the stdio MCP server to exit immediately after initialize, before tools/list can be answered. Source: issue #1577
• JetBrains auto-launch can start an IDE during CLI commands such as serena print-system-prompt. Source: issue #1578
• Command injection in the JetBrains launch path (subprocess.Popen(cmd, shell=True)) is tracked as a critical-severity finding. Source: issue #1585
• Hook crashes in serena-hooks when Copilot CLI sends tool_input as a plain string for freeform tools such as apply_patch. Source: issue #1583

The most recent tagged release, v1.5.3, contains no functional changes and only adds a registry identifier to enable publishing to GitHub's MCP registry; functional changes are tracked through v1.5.2 and the project changelog.

See Also

• Language Server Protocol Types
• SolidLSP Server Implementation
• Agent and Tool Dispatch
• Multi-Language Projects

Related Pages

Related topics: Overview & System Architecture, Language Server Backend (solidlsp)

Core Agent & Tool System

Overview

The Core Agent & Tool System is the central runtime of Serena: it binds an MCP-facing agent (SerenaAgent) to a structured set of Tool classes that the LLM client can invoke. Tools are thin wrappers over two underlying engines — the SolidLSP language-server integration for symbol-level semantics, and the project's local filesystem/memory layer. The agent exposes an MCP tool surface, dispatches calls, manages project activation state, and integrates with JetBrains IDEs and CLI hooks.

This module is what differentiates Serena from text-only editing assistants. As the README highlights, independent evaluations converge on the same verdict: Serena's IDE-backed semantic tools collapse multi-step refactors (cross-file renames, moves, reference lookups) into a single atomic call. Source: README.md

Agent Architecture

SerenaAgent (in src/serena/agent.py) is the long-lived controller for a session. It owns:

• The active Project and its language-server pool.
• A MemoryManager for project-scoped and global memories.
• A PromptFactory for assembling onboarding and initial-instruction prompts.
• Tool registration, exposure filtering, and invocation routing.

When an MCP client connects, the agent enumerates enabled tools, applies per-project filters, and serves them through the MCP protocol. Non-project commands (such as serena print-system-prompt) also construct a SerenaAgent, which is why community issue #1578 reports that "Serena cli commands may start IDE" — CLI commands inadvertently instantiate the agent and trigger the JetBrains auto-launch path. Source: #1578

Security note (JetBrains launcher)

A documented security concern at src/serena/agent.py:1222 uses subprocess.Popen(cmd, shell=True) to launch JetBrains IDEs. Because jetbrains_launch_command originates from external configuration, a tampered config can lead to arbitrary OS command execution. The maintainers mark this as Critical. Source: #1585

Tool System

The Tool base class lives in src/serena/tools/tools_base.py. Each tool subclasses Tool and implements apply(...); the framework injects the active agent and the memory_manager and enforces marker-based exposure rules:

The framework resolves session_id and other request metadata automatically and dispatches the call into apply(). The agent-side filter tool_is_exposed(name) decides whether a tool appears in the MCP tools/list response.

Workflow tools

src/serena/tools/workflow_tools.py ships the lifecycle tools:

• OnboardingTool.apply() — Detects the platform via platform.system(), ensures the memory-maintenance memory exists (memory_manager.ensure_memory_maintenance_memory()), and returns the onboarding prompt that instructs the agent how to record project conventions. It short-circuits if WriteMemoryTool is not exposed, and it is documented as "at most once per conversation."
• InitialInstructionsTool.apply(session_id) — Returns the "Serena Instructions Manual" for clients that do not surface initial instructions at MCP connect time. Marked ToolMarkerDoesNotRequireActiveProject.

Source: src/serena/tools/workflow_tools.py

Tool exposure and language restrictions

When a project specifies a languages: list, the agent narrows the language server set accordingly. Misconfiguration here has surfaced in issue #1577, where enabling julia causes the stdio MCP server to exit a few milliseconds after initialize, before answering tools/list, producing the client error "tools fetch failed." Source: #1577

LSP Integration

The agent's symbol tools sit on top of SolidLSP, which conforms to LSP v3.17.

• Type system. src/solidlsp/lsp_protocol_handler/lsp_types.py contains TypedDict definitions mirroring the upstream LSP TypeScript spec (e.g., ReferenceClientCapabilities, DefinitionClientCapabilities, CodeActionParams, MarkupKind, PositionEncodingKind). The file header notes it is generated from the upstream specification and targeted for ts2python-based regeneration.
• Request surface. src/solidlsp/lsp_protocol_handler/lsp_requests.py exposes async helpers such as type_definition, document_color, color_presentation, and folding_range. Each forwards to send_request(method, params).
• Wire-level constants. src/solidlsp/lsp_protocol_handler/lsp_constants.py defines the canonical JSON keys (URI, RANGE, POSITION, TEXT_DOCUMENT, LANGUAGE_ID, VERSION, TEXT) used in every request payload.

flowchart LR
    Client[MCP Client] -->|tools/list, tools/call| Agent[SerenaAgent]
    Agent -->|dispatch| Tool[Tool subclass]
    Tool -->|symbol op| LS[Language Server Pool]
    LS -->|LSP v3.17| LTServer[tsserver / clangd / jdtls / ...]
    Tool -->|read/write| FS[(Project Filesystem)]
    Tool -->|notes| Mem[MemoryManager]

Known semantic-tool caveats

Issue #1586 documents a TypeScript-specific asymmetry: find_referencing_symbols (which calls textDocument/references) returns 0, while find_symbol and find_definition work. The root cause is that tsserver loads files as inferred projects rather than the project's real tsconfig.json, so cross-file reference resolution misses most callers. Source: #1586

Hooks, CLI, and Known Failure Modes

The agent system also includes PreToolUse hooks (e.g., PreToolUseRemindAboutSymbolicTools) that nudge the model back toward semantic tools. Issue #1583 reports a crash in Copilot CLI on PreToolUse events for freeform tools (apply_patch) because hook code assumes tool_input is always a JSON object and calls .get() on it, while Copilot delivers the raw patch string. Source: #1583

Multi-language projects

Issue #611 and #192 track the open work on MultiLanguageLS — supporting a single project that mixes Dart, Java, and TypeScript. Process isolation across language servers remains an in-progress design constraint.

Release lineage

Releases through v1.5.3 (latest) include the onboarding hotfix (v1.5.1), and v1.5.3 adds only an MCP-registry identifier with no functional changes. Sources: v1.5.3, v1.5.1

See Also

• Memory & Project Configuration
• SolidLSP Language Server Backends
• JetBrains Plugin Integration
• MCP Client Integration Guide

Related Pages

Related topics: Overview & System Architecture, Core Agent & Tool System, Configuration, Deployment & Operations

Language Server Backend (solidlsp)

Purpose and Scope

The solidlsp package is Serena's default code-analysis backend. It provides a uniform Python interface to a wide collection of language servers that implement the Language Server Protocol (LSP). Through this abstraction, Serena can offer symbol search, reference finding, go-to-definition, hover, rename, and other structural editing features across more than 40 programming languages without implementing parsing for each one. Source: README.md

The backend sits between Serena's high-level agent tools (e.g. the symbol and editing tools in src/serena/tools/symbol_tools.py) and the third-party language servers that do the actual semantic work. It is organised so that each supported language is plugged in as a small subclass that knows how to spawn its server process and what file extensions to recognise; everything else — the JSON-RPC transport, type definitions, request lifecycle, and error handling — is shared infrastructure.

The primary alternative to solidlsp is the paid Serena JetBrains Plugin, which delegates analysis to the user's running JetBrains IDE and therefore supports all languages JetBrains supports, including those without a public LSP server. Source: README.md

Architecture

flowchart LR
    A[Serena Agent / MCP Tools] --> B[symbol_tools.py]
    B --> C[ls.py - SolidLanguageServer]
    C --> D[ls_request.py - Request/Response]
    C --> E[ls_process.py - Process Lifecycle]
    C --> F[ls_config.py - Language Configuration]
    D --> G[lsp_types.py - LSP 3.17 Types]
    D --> H[server.py - JSON-RPC Client]
    E --> H
    H --> I[(External LSP Server<br/>e.g. pyright, tsserver, gopls)]
    I --> H
    H --> D
    D --> C
    C --> B
    F --> C

The data flow is request-driven: an agent tool such as find_referencing_symbols builds an LSP request (typed against src/solidlsp/ls_types.py), submits it through src/solidlsp/ls_request.py, which hands the framed JSON-RPC message to the transport in src/solidlsp/lsp_protocol_handler/server.py. The transport is the read/write loop that speaks LSP over the server process's stdio, originally derived from the OLSP project. Source: src/solidlsp/lsp_protocol_handler/server.py

The process is spawned and supervised by src/solidlsp/ls_process.py, which also handles clean shutdown. Per-language behaviour — which executable to launch, which file globs belong to the language, which directories to ignore, and which initialisation options to send — lives in src/solidlsp/ls_config.py and in language-specific subclasses located under src/solidlsp/language_servers/. The Elixir integration (src/solidlsp/language_servers/elixir_tools/README.md) is representative: it wraps the official Expert language server, filters Elixir build directories (_build/, deps/, .elixir_ls/, cover/), and downloads the expert binary automatically when missing.

Core Components

SolidLanguageServer (ls.py)

The SolidLanguageServer class is the public entry point used by Serena's tools. It exposes high-level methods that translate Pythonic calls (e.g. request a symbol's references) into LSP requests and map the response back into Serena's own LanguageServerSymbol data model. Source: src/solidlsp/ls.py

Request Layer (ls_request.py and lsp_requests.py)

src/solidlsp/ls_request.py defines the request/response primitives that SolidLanguageServer builds on top of the JSON-RPC transport. The autogenerated counterpart in src/solidlsp/lsp_protocol_handler/lsp_requests.py provides typed wrappers for every standard LSP method (definition, references, typeDefinition, documentSymbol, etc.) against the LSP 3.17 specification. Source: src/solidlsp/lsp_protocol_handler/lsp_requests.py

Transport (lsp_protocol_handler/server.py)

The JSON-RPC client launches the language server as a child process and exchanges LSP messages over its stdin/stdout, framing each message with a Content-Length header as required by the protocol. Source: src/solidlsp/lsp_protocol_handler/server.py

Type and Exception Definitions (ls_types.py, lsp_types.py, ls_exceptions.py)

• src/solidlsp/ls_types.py defines Serena-side types such as LanguageServerSymbol and ReferenceInSymbol that tools like find_referencing_symbols return. Source: src/serena/tools/symbol_tools.py
• src/solidlsp/lsp_protocol_handler/lsp_types.py is the autogenerated mirror of the LSP 3.17 TypeScript types (e.g. SemanticTokenTypes, DiagnosticSeverity, MarkupKind).
• src/solidlsp/ls_exceptions.py centralises the error types that the request layer can raise when a server reports a protocol error or fails to start.

Process Management (ls_process.py)

Responsible for spawning the language server, capturing logs, detecting early exit, and terminating the process on disposal. Process-level failures (e.g. the server crashing during initialize) surface here before they reach the MCP layer. Source: src/solidlsp/ls_process.py

Configuration and Language Support

Each supported language is registered through src/solidlsp/ls_config.py, which carries the executable command, required runtime (e.g. Java for some Java language servers, Node for tsserver), startup timeout, and the list of file extensions or glob patterns that identify the language inside a project. The Elixir integration, for example, declares expert --stdio as its command, elixir as the language identifier, and .ex/.exs as recognised extensions. Source: src/solidlsp/language_servers/elixir_tools/README.md

Per-project configuration is supplied at the MCP level (e.g. through the languages: list passed in the project activation). When a language is listed, Serena instantiates the corresponding SolidLanguageServer subclass, starts its process, sends initialize, and only then exposes the language's tools.

The backend ships with integrations covering Ada/SPARK, AL, Angular, Ansible, Bash, BSL, C#, C/C++, Clojure, Crystal, CUE, Dart, Elixir, Elm, Erlang, Fortran, F#, GDScript, GLSL, Go, Groovy, Haskell, Haxe, HLSL, HTML, Java, JavaScript, JSON, Julia, Kotlin, Lean 4, Lua, Luau, Markdown, MATLAB, mSL, Nix, OCaml, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, SCSS/Sass/CSS, Solidity, Svelte, Swift, TOML, TypeScript, WGSL, YAML, and Zig. Source: README.md

Known Limitations and Community-Reported Issues

Several recurring community reports trace back to the language server backend:

• TypeScript reference lookup returning zero results. Because tsserver can be started in "inferred project" mode when no tsconfig.json is reachable, find_referencing_symbols may legitimately find nothing even though find_symbol and definition succeed. This is the symptom tracked in issue #1586 and points at how the TypeScript integration must be configured to bind the server to the project's real tsconfig.json.
• Language servers that crash during initialize. When the Julia language server is enabled it can take down the stdio MCP transport a few milliseconds after initialize, before the tools/list response is produced. See issue #1577. Solidls reports this through ls_process.py, but the MCP server has already exited by the time the failure is observable.
• Multi-language projects. Configuring multiple language servers for a single project is supported but still being stabilised (see issue #192 and the long-standing request in issue #611). Projects that mix, for example, Dart, Java, and TypeScript currently need explicit languages: entries to enable each backend.
• Missing language servers. Languages that do not have a free or easily automatable LSP server (e.g. Swift in the original community discussion) are either not supported or rely on the JetBrains Plugin. See issue #198.
• Client integration failures. When solidls cannot start, the most common user-facing symptom is "Failed to connect in Claude code" (see issue #494), which is usually a server startup, dashboard, or process-isolation problem rather than a bug in the LSP plumbing itself.

When the solidls backend cannot satisfy a request — either because the project language is unsupported, the server binary is missing, or the server process died — the exception types declared in src/solidlsp/ls_exceptions.py are raised and propagated through the agent tool layer, so callers can distinguish between a missing-language configuration and a real LSP error.

See Also

• Serena README
• Language Server Protocol Specification, 3.17
• Issue #1586 — TypeScript find_referencing_symbols returns 0
• Issue #1577 — Julia language server kills stdio MCP
• Issue #611 — Multi-language project support
• Issue #198 — Swift language support
• Issue #494 — Failed to connect in Claude code

Related Pages

Related topics: Overview & System Architecture, Core Agent & Tool System, Language Server Backend (solidlsp)

Configuration, Deployment & Operations

Overview

Serena is an MCP (Model Context Protocol) server that exposes symbolic code retrieval and editing tools to AI coding agents. Its configuration, deployment, and operational surface is shaped by three concerns: project-level YAML configuration, the JSON-RPC 2.0 transport used to talk to language servers (and the MCP client), and the lifecycle of language server processes spawned per project. Understanding how these layers interact is essential for diagnosing the failure modes reported in the community (issues #1577, #1578, #1585, #1586).

Configuration System

Project configuration is loaded from a YAML file and normalized into a typed dataclass. The loader preserves comments and applies defaults for missing fields so older or partial configurations continue to work without modification. from_yaml in src/serena/config/serena_config.py reads the file, iterates over dataclasses.fields(cls), and applies defaults via get_dataclass_default. The function returns a tuple (dict, was_complete) so callers can distinguish between a user-supplied complete config and one that required defaults.

# Excerpt — src/serena/config/serena_config.py
for field_info in dataclasses.fields(cls):
    key = field_info.name
    if key.startswith("_"):
        continue
    if key in cls.FIELDS_WITHOUT_DEFAULTS:
        continue
    if key not in data:
        was_complete = False
        default_value = get_dataclass_default(cls, key)
        data.setdefault(key, default_value)

Backward compatibility is handled explicitly: a legacy single language key is converted into a languages list, and project.local.yml overlays are supported (which may be highly incomplete). This matters in practice because MultiLanguageLS and per-language LSP selection depend on the languages list shape (tracking issue #192, user requests #611).

Deployment: MCP and Language Server Transports

Serena runs as an MCP server that, in turn, spawns one or more language server processes. The language server transport is JSON-RPC 2.0 over stdio with Content-Length framing. make_request and make_notification in src/solidlsp/lsp_protocol_handler/server.py construct well-formed envelopes:

return {"jsonrpc": "2.0", "method": method, "id": request_id, **_build_params_field(method, params)}

Two compatibility constraints shape the framing:

Because every byte of wire compatibility flows through this layer, deployment bugs often look like transport errors. For example, with the julia language server enabled, Serena's stdio MCP server exits a few milliseconds after initialize, before tools/list can be served (#1577). The root cause is a language-server process that crashes the surrounding MCP loop — not a protocol bug — but the symptom is reported as "tools fetch failed" by MCP clients such as Claude Code (#494).

Language Server Configuration and Tooling

The configuration layer above ultimately selects which language servers are spawned for a given project. Each LanguageServer instance issues typed LSP requests through src/solidlsp/lsp_protocol_handler/lsp_requests.py (e.g. typeDefinition, document_color, folding_range) against the schema defined in src/solidlsp/lsp_protocol_handler/lsp_types.py. Field names on the wire — uri, range, textDocument, position, languageId — are centralized in src/solidlsp/lsp_protocol_handler/lsp_constants.py so request construction and server parsing never drift.

A known operational pitfall is TypeScript: find_referencing_symbols returns 0 because tsserver loads files as inferred projects rather than from the real tsconfig.json (#1586). find_symbol, get_symbols_overview, and find_definition still work because they operate on a single buffer, while reference search needs the full project graph. The remediation is to ensure a real tsconfig.json is present and reachable from the project root before launching the MCP server.

Operations and Common Failure Modes

IDE auto-launch

Recent versions auto-launch JetBrains when SerenaAgent is initialized. Commands that rely on SerenaAgent but are otherwise non-interactive — for example serena print-system-prompt — now spawn an IDE as a side effect (#1578). Log-level overrides are also not respected in that path. Workarounds typically involve running these commands without a project context or disabling the JetBrains launcher in the config.

Security: shell invocation

A critical command-injection vector was reported in src/serena/agent.py around line 1222, where subprocess.Popen(cmd, shell=True) is used to launch JetBrains (#1585). Because jetbrains_launch_command is read from the external config file, a tampered config can lead to arbitrary OS command execution. Operators should treat project.yml and any project.local.yml overlay as security-sensitive inputs and prefer argument-list invocation over shell=True for untrusted values.

Hooks and freeform tools

On Copilot CLI, PreToolUse hooks for freeform tools like apply_patch receive tool_input as a plain string rather than a JSON object, which crashes PreToolUseRemindAboutSymbolicTools when it calls .get() on the input (#1583). Defensive code must check whether the input is a dict before treating it as one.

Multi-language projects

The MultiLanguageLS work (tracking in #192, originating from #168) enables configuring more than one LSP for cross-language projects (see #611). Process isolation makes the merge non-trivial: each LSP runs in its own subprocess, and the agent must route requests to the correct one based on file language.

Release Cadence

Serena follows semantic versioning with a roughly monthly cadence. The latest release as of this writing is v1.5.3, which contains no functional changes and only adds the identifier required to publish Serena to GitHub's MCP registry. Prior releases (v1.5.0, v1.3.0, v1.2.0, v1.1.0, v1.0.0) are documented in the change log. Operators upgrading across versions should re-validate their project.yml, because configuration schema evolution is handled by from_yaml's backward-compatibility layer rather than by a dedicated migration tool.

See Also

• Project configuration loader: src/serena/config/serena_config.py
• JSON-RPC transport: src/solidlsp/lsp_protocol_handler/server.py
• LSP type schema: src/solidlsp/lsp_protocol_handler/lsp_types.py
• LSP request surface: src/solidlsp/lsp_protocol_handler/lsp_requests.py
• Wire field constants: src/solidlsp/lsp_protocol_handler/lsp_constants.py
• Multi-language LSP tracking issue: #192
• Security advisory (command injection): #1585

Doramagic Pitfall Log

Found 12 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Runtime risk - Runtime risk requires verification.

1. Runtime risk: Runtime risk requires verification

• Severity: high
• Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/oraios/serena/issues/1578

2. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/oraios/serena/issues/1577

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/oraios/serena/issues/1586

4. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/oraios/serena

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/oraios/serena/issues/1583

6. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/oraios/serena

7. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/oraios/serena

8. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/oraios/serena

9. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/oraios/serena

10. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/oraios/serena/issues/1585

11. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/oraios/serena

12. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/oraios/serena

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using serena with real data or production workflows.

• find_referencing_symbols returns 0 for TypeScript while find_symbol/defi - github / github_issue
• Security: COMMAND_INJECTION in agent.py:1222 (subprocess shell=True) - github / github_issue
• Enabling the julia language server kills the STDIO MCP server right af - github / github_issue
• serena-hooks remind crashes on Copilot CLI PreToolUse events for freefor - github / github_issue
• Serena cli commands may start IDE - github / github_issue
• v1.5.3 - github / github_release
• v1.5.2 - github / github_release
• v1.5.1 - github / github_release
• v1.5.0 - github / github_release
• v1.3.0 - github / github_release
• v1.2.0 - github / github_release
• v1.1.2 - github / github_release