mirror of
https://github.com/headroomlabs-ai/headroom.git
synced 2026-08-27 14:17:10 -04:00
## Description
`_ensure_serena_dashboard_disabled()` wrote a one-key bootstrap config
(`web_dashboard_open_on_launch: false`) into
`~/.serena/serena_config.yml` when the file was absent, assuming Serena
fills in any key it omits.
Verified against **Serena 1.6.2.dev0**
(`serena/config/serena_config.py`), that holds for every field except
one. Serena autogenerates its own complete config **only when the path
does not exist**:
```python
if not os.path.exists(config_file_path):
cls._generate_config_file(config_file_path)
```
Once any file is present it validates instead. Every other field falls
back to a dataclass default via `get_value_or_default`, but a missing
`projects` key is fatal (~line 1064):
```
SerenaConfigError: `projects` key not found in Serena configuration.
```
So Headroom's own bootstrap file killed Serena on **every machine
without a pre-existing Serena config**. The MCP server exited during
handshake — surfacing as `connection closed: initialize response` on
Codex and a bare `MCP error -32000: Connection closed` on OpenCode
(#2674) — and `serena project index` failed identically.
Headroom now leaves that file to Serena. That is immune to Serena adding
required keys later; guessing the schema is what caused the outage. The
popup never needed the file anyway: `build_serena_spec` passes
`--open-web-dashboard False`, which Serena applies *after* loading the
config (`serena/mcp.py:361` — `config.web_dashboard_open_on_launch =
open_web_dashboard`), so the flag wins regardless of what is on disk.
An **existing** config is still edited in place — dashboard key flipped,
`projects: []` backfilled to repair machines an affected version already
wrote — preserving a populated `projects` list, other keys and comments.
Closes #2674
## Type of Change
- [x] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [ ] Performance improvement
- [x] Code refactoring (no functional changes)
## Changes Made
- `_ensure_serena_dashboard_disabled()` never creates
`serena_config.yml`; it only edits an existing one, and backfills
`projects: []` there to repair already-broken machines.
- Dropped `_scope_serena_languages` + `_detect_repo_languages` +
`_EXT_TO_SERENA_LANGUAGE` (**−133 lines**). Dead weight: Serena
determines languages itself in `ProjectConfig.autogenerate`
(`_determine_project_language_servers`) and records them under
`language_servers` — `languages`, which Headroom wrote, is a legacy name
Serena migrates via `RENAMED_FIELDS`. Serena's generated file uses a
block-style list, so our single-line-flow regex never matched it: on any
Serena-generated `project.yml` the function was a **verified no-op**.
The only case where it acted was creating the file — the same
partial-config trap — which also skipped the `project.local.yml` sidecar
Serena writes alongside.
- **Test isolation:** the MCP install ledger defaults to
`~/.headroom/mcp_installs.json`, so any test registering a server wrote
into the developer's real ledger (observed adding a live `claude/serena`
entry during a local run). `conftest.py` now redirects it per-test.
- **Repo config:** `.serena/project.yml` carried a stale `project_name`
(`"feature-opencode-wrap"`) and listed only `typescript`, so Serena's
symbol index skipped 1331 Python and 194 Rust files for every
contributor.
## Testing
- [x] Unit tests pass (`pytest`)
- [x] Linting passes (`ruff check .`)
- [x] Type checking passes (`mypy headroom`)
- [x] New tests added for new functionality
- [x] Manual testing performed
### Test Output
```text
$ pytest tests/test_wrap_code_memory.py tests/test_cli/test_wrap_serena_boost.py \
tests/test_cli/test_serena_migrate.py tests/test_cli/test_serena_disable.py -q
35 passed, 1 skipped in 0.84s
$ SERENA_SRC=<serena checkout> pytest tests/test_wrap_code_memory.py -q
13 passed in 0.62s # the skipped test runs when a Serena source tree is available
$ ruff check headroom/ tests/ --exclude headroom/dashboard/templates
All checks passed!
$ mypy headroom/cli/wrap.py
Success: no issues found in 1 source file
```
New tests. The key one asserts the invariant rather than our own key
list, so it stays correct even if Serena adds a required key — a test
pinning `projects: []` would keep passing while users broke again:
- `test_serena_config_is_never_created_by_headroom` — Headroom must not
pre-empt Serena's bootstrap
- `test_serena_dashboard_disabled_repairs_config_missing_projects` —
heals a config an affected version wrote
- `test_serena_dashboard_disabled_preserves_registered_projects` — never
clobbers the real registry; comments kept, no duplicate key
- `test_serena_dashboard_disabled_is_idempotent`
- `test_serena_config_required_keys_match_serena_source` — reads
Serena's real source and pins the two facts this fix rests on
(bootstrap-only-when-absent, `projects` is the sole fatal omission).
Skipped unless `SERENA_SRC` is set; deliberately **not** named
`HEADROOM_*` because `conftest.py` scrubs that namespace, which would
make it silently always-skip.
## Real Behavior Proof
- **Environment:** macOS 15.4 (darwin 25.4.0), Python 3.12.6, Serena
1.6.2.dev0 via `uvx --from git+https://github.com/oraios/serena`, Codex
CLI 0.146.0.
- **Exact command / steps:** a probe doing a real JSON-RPC `initialize`
handshake against the exact command `headroom wrap` registers — i.e.
what Codex/OpenCode actually do — in a throwaway `HOME` per case. (A)
pre-seeded with the one-line config an affected version wrote; (B) no
config; (C) real `headroom wrap codex --prepare-only`, then handshake.
- **Observed result:**
```text
=== A. BROKEN: single-key config (Headroom 0.33.0) ===
MCP handshake: FAIL — no initialize response (exit=1). stderr tail:
File ".../serena/config/serena_config.py", line 1064, in from_config_file
raise SerenaConfigError("`projects` key not found in Serena configuration. ...")
serena.config.serena_config.SerenaConfigError: `projects` key not found ...
config after run: 1 lines, has 'projects': False
=== B. FIXED: no config, Serena bootstraps it ===
MCP handshake: PASS — initialize OK — serverInfo.name='Serena'
config after run: 213 lines, has 'projects': True
=== C. FULL FLOW: real `headroom wrap codex` then handshake ===
Serena: no serena_config.yml yet — letting Serena generate it
Serena MCP: registered (restart OpenAI Codex CLI if it was already running)
Serena: project pre-indexed (symbol cache warmed)
serena_config.yml: 213 lines, written by Serena (correct)
MCP handshake: PASS — initialize OK — serverInfo.name='Serena'
--- verdict ---
A (broken config) started: False <- expected False
B (fixed, no config) started: True <- expected True
C (after real wrap) started: True <- expected True
```
A second `wrap` in the same HOME flips the dashboard without damage:
`true` → `false`, `projects` intact, all 153 comment lines intact. The
writer was isolated against a pristine 213-line Serena config: **delta 0
newlines**.
- **Not tested:** Windows and Linux (macOS only); Serena versions other
than 1.6.2.dev0; the JetBrains language backend. The probe needs network
+ `uvx` (~2 min) so it is a manual verification tool, not wired into CI.
## Review Readiness
- [x] I have performed a self-review
- [x] This PR is ready for human review
## Checklist
- [x] My code follows the project's style guidelines
- [x] I have performed a self-review of my code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [x] I did **not** edit `CHANGELOG.md` — it is generated by
release-please from my Conventional Commit PR title (a CI guard enforces
this)
## Additional Notes
- **Docs:** N/A — no user-facing docs described the `serena_config.yml`
bootstrap or the language scoping.
- Also fixes the OpenCode report (#2674). The Codex-side report of the
same root cause quotes the `SerenaConfigError` verbatim; OpenCode only
surfaces the generic `-32000`, which is why it read as two different
bugs.
- Users already broken by an affected version are repaired automatically
on their next `headroom wrap` — no manual `serena_config.yml` edit
needed.
- A stacked PR removing the rtk/lean-ctx CLI context tools is based on
this branch; this one is deliberately small so it can land first.
169 lines
9.4 KiB
YAML
169 lines
9.4 KiB
YAML
# the name by which the project can be referenced within Serena/when chatting with the LLM.
|
||
project_name: "headroom"
|
||
|
||
# the encoding used by text files in the project
|
||
# For a list of possible encodings, see https://docs.python.org/3.11/library/codecs.html#standard-encodings
|
||
encoding: "utf-8"
|
||
|
||
# line ending convention to use when writing source files.
|
||
# Possible values: unset (use global setting), "lf", "crlf", or "native" (platform default)
|
||
# This does not affect Serena's own files (e.g. memories and configuration files), which always use native line endings.
|
||
line_ending:
|
||
|
||
# The language backend to use for this project.
|
||
# If not set, the global setting from serena_config.yml is used.
|
||
# Valid values: LSP, JetBrains
|
||
# Note: the backend is fixed at startup. If a project with a different backend
|
||
# is activated post-init, an error will be returned.
|
||
language_backend:
|
||
|
||
# whether to use project's .gitignore files to ignore files
|
||
ignore_all_files_in_gitignore: true
|
||
|
||
# advanced configuration option allowing to configure language server-specific options.
|
||
# Maps the language key to the options.
|
||
# The settings are considered only if the project is trusted (see global configuration to define trusted projects).
|
||
# See https://oraios.github.io/serena/02-usage/050_configuration.html#language-server-specific-settings
|
||
ls_specific_settings: {}
|
||
|
||
# list of additional paths to ignore in this project.
|
||
# Same syntax as gitignore, so you can use * and **.
|
||
# Important: quote patterns that start with `*`, otherwise YAML treats them as aliases.
|
||
# Example:
|
||
# ignored_paths:
|
||
# - "examples/**"
|
||
# - ".worktrees/**"
|
||
# - "**/bin/**"
|
||
# - "**/obj/**"
|
||
# Note: global ignored_paths from serena_config.yml are also applied additively.
|
||
ignored_paths: []
|
||
|
||
# whether the project is in read-only mode
|
||
# If set to true, all editing tools will be disabled and attempts to use them will result in an error
|
||
# Added on 2025-04-18
|
||
read_only: false
|
||
|
||
# list of tool names to exclude.
|
||
# This extends the existing exclusions (e.g. from the global configuration)
|
||
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||
excluded_tools: []
|
||
|
||
# list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
|
||
# This extends the existing inclusions (e.g. from the global configuration).
|
||
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||
included_optional_tools: []
|
||
|
||
# fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
|
||
# This cannot be combined with non-empty excluded_tools or included_optional_tools.
|
||
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||
fixed_tools: []
|
||
|
||
# list of mode names that are to be activated by default, overriding the setting in the global configuration.
|
||
# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
|
||
# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
|
||
# Otherwise, this overrides the setting from the global configuration (serena_config.yml).
|
||
# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
|
||
# for this project.
|
||
# This setting can, in turn, be overridden by CLI parameters (--mode).
|
||
# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
|
||
default_modes:
|
||
|
||
# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
|
||
# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
|
||
# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
|
||
added_modes:
|
||
|
||
# initial prompt for the project. It will always be given to the LLM upon activating the project
|
||
# (contrary to the memories, which are loaded on demand).
|
||
initial_prompt: ""
|
||
|
||
# time budget (seconds) per tool call for the retrieval of additional symbol information
|
||
# such as docstrings or parameter information.
|
||
# This overrides the corresponding setting in the global configuration; see the documentation there.
|
||
# If null or missing, use the setting from the global configuration.
|
||
symbol_info_budget:
|
||
|
||
# list of regex patterns which, when matched, mark a memory entry as read‑only.
|
||
# Extends the list from the global configuration, merging the two lists.
|
||
read_only_memory_patterns: []
|
||
|
||
# list of regex patterns for memories to completely ignore.
|
||
# Matching memories will not appear in list_memories or activate_project output
|
||
# and cannot be accessed via read_memory or write_memory.
|
||
# To access ignored memory files, use the read_file tool on the raw file path.
|
||
# Extends the list from the global configuration, merging the two lists.
|
||
# Example: ["_archive/.*", "_episodes/.*"]
|
||
ignored_memory_patterns: []
|
||
|
||
# list of additional workspace folder paths for cross-package reference support.
|
||
# Paths can be absolute or relative to the project root.
|
||
# Each folder is registered as an LSP workspace folder, enabling language servers to discover
|
||
# symbols and references across package boundaries, but these folders are not indexed by Serena,
|
||
# i.e. the respective symbols will not be found using Serena's symbol search tools.
|
||
# Example:
|
||
# additional_workspace_folders:
|
||
# - ../sibling-package
|
||
# - ../shared-lib
|
||
ls_additional_workspace_folders: []
|
||
|
||
# list of language servers to start when using the LSP backend; choose from:
|
||
# ada al angular ansible bash
|
||
# bsl clojure cpp cpp_ccls crystal
|
||
# csharp csharp_omnisharp cue dart elixir
|
||
# elm erlang fortran fsharp gdscript
|
||
# go groovy haskell haxe hlsl
|
||
# html java json julia kotlin
|
||
# latex lean4 lua luau markdown
|
||
# matlab msl nix ocaml pascal
|
||
# perl php php_phpactor php_phpantom powershell
|
||
# python python_basedpyright python_jedi python_pyrefly python_ty
|
||
# qml r rego ruby ruby_solargraph
|
||
# rust scala scss solidity svelte
|
||
# swift systemverilog terraform toml typescript
|
||
# typescript_vts vue yaml zig
|
||
# (This list may be outdated; generated with scripts/print_language_list.py;
|
||
# For the current list, see values of the LanguageServerId enum here:
|
||
# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py)
|
||
# For some languages, there are several alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
|
||
# Note:
|
||
# - For C, use cpp
|
||
# - For JavaScript, use typescript
|
||
# - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
|
||
# - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
|
||
# - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
|
||
# - For Free Pascal/Lazarus, use pascal
|
||
# Special requirements:
|
||
# Some language servers require additional setup/installations.
|
||
# See here for details: https://oraios.github.io/serena/01-about/020_programming-languages.html#language-servers
|
||
# When using multiple language servers, the first language server that supports a given file will be used for that file.
|
||
# The first language server is the default language and the respective language server will be used as a fallback.
|
||
# Note that when using the JetBrains backend, language servers are not used and this list is correspondingly ignored.
|
||
language_servers:
|
||
- python
|
||
- rust
|
||
- typescript
|
||
|
||
# list of workspace folder paths (LSP backend only).
|
||
# These folders will be used to build up Serena's symbol index.
|
||
# Paths must be within the project root and should thus be relative to the project root.
|
||
# Furthermore, the paths should not be filtered by ignore settings.
|
||
# Default setting: The entire project root folder (".") is considered.
|
||
# In (large) monorepos, this can be used to index only subfolders of the project root, e.g.
|
||
# ls_workspace_folders:
|
||
# - "./subproject1"
|
||
# - "./subproject2"
|
||
ls_workspace_folders:
|
||
- .
|
||
|
||
# optional shell command to run before the language backend (LSP or JetBrains) is initialised.
|
||
# the command runs in the project root directory and is only executed if the project is trusted
|
||
# (see trusted_project_path_patterns in the global configuration).
|
||
# serena waits for the command to exit: a non-zero exit code is logged as an error but does not
|
||
# abort activation. a per-project timeout (activation_command_timeout, default 180s) is the safety
|
||
# backstop for non-terminating commands; on expiry the process is killed and activation continues.
|
||
# example: activation_command: "npx nx run-many -t build"
|
||
activation_command:
|
||
|
||
# maximum time in seconds to wait for activation_command to complete before killing it (default 180s).
|
||
# must be a positive number.
|
||
activation_command_timeout: 180.0
|