Even though lists are explicitly supported on Windows,
the subprocess implementation does not guarantee that shell
metacharacters are appropriately escaped, i.e. the individual
list elements are not necessarily treated as atomic arguments.
oslex provides an abstraction layer which works across platforms.
Context or mode argument referencing a known name (e.g. `--context anitgravity`) could result in
incorrect file access if a corresponding local file existed (e.g. `./antigravity` binary);
file access is now guarded with path detection (file ending or path separator must be present)
Fixes#1558
Bug: with `languages: [svelte]` (the documented setup), find_symbol/get_symbols_overview returned
empty for .ts/.js files, and find_referencing_symbols failed with "No symbol matching '<name>'
found". Symbols living in plain .ts/.js modules (services, stores, types, utils) were undiscoverable
through Serena's symbolic tools.
Cause: SvelteLanguageServer delegated references/definition/rename/diagnostics for .ts/.js files to
the companion (svelte-plugin-aware) TS server, but had no override for document-symbol requests. So
documentSymbol on a .ts/.js file was answered by the base svelte LS, which only serves .svelte
files, and returned nothing. Since find_symbol/get_symbols_overview are backed by documentSymbol --
and find_referencing_symbols must first locate the target symbol the same way -- the discovery step
never reached the companion.
Fix: override request_document_symbols to route .ts/.js files to the companion TS server, mirroring
the existing delegations. This is the single method that all symbol-tree/overview/containing-symbol
paths flow through, so it restores discovery for find_symbol, get_symbols_overview,
find_referencing_symbols and symbol-based editing in one place.
Tests: add .ts document-symbol and overview coverage plus agent-level symbol-retriever tests;
strengthen the existing symbol-tree test to assert GAME_VERSION, a symbol defined only in a .ts file
(the prior assertions also matched .svelte definitions, which is why the regression went unnoticed).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Make SerenaConfig.save private, because it is not a method that should
ever be called on a runtime instance; it is purely an internal operation
* Refactor the CLI init command appropriately (which used the save method)
* Improve comments to make usage limitations clear
* Improve the changelog entry to make error conditions more concrete
Bug: `serena start-mcp-server --language-backend X --project <newdir>` silently rewrote the global
serena_config.yml's language_backend to X. Cause: a not-yet-registered --project is auto-registered, and
SerenaConfig.save() rewrote the WHOLE file from the in-memory config — which by then carried the CLI
--language-backend override (and would equally carry --log-level / --tool-timeout / etc.).
Fix: project (de)registration now persists ONLY the projects list. add_registered_project / remove_project go
through a new _persist_projects(), which re-loads the on-disk config, copies in the current project list, and
saves that — so a transient runtime override of any field can never be written back.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Fix find_project_root hijacking git worktrees nested under a Serena project
find_project_root searched all ancestor levels for .serena/project.yml
before ever looking for .git. A git worktree whose own .git is a pointer
file, nested under a directory that is an explicit Serena project, was
resolved to the ancestor project instead of the worktree. With CLI agents
that launch via --project-from-cwd (Claude Code, Codex, Gemini), this
silently bound the server to the wrong working tree: reads returned stale
symbols and edits landed in the parent repo.
Walk up in a single pass so the nearest project boundary wins, whether it
is a .serena/project.yml or a .git (dir or worktree/submodule pointer
file). Same-level behavior is unchanged. Adds a regression test.
* Document worktree project-root fix in changelog and usage docs
upon project activation
Serena searches for the plugin instance upon project activation, and if the instance is not found
and the setting is configured, launches a new IDE instance based on the command
* Remove obsolete/outdated content
* git-worktree:
- Remove incorrect recommendation to copy the entire .serena folder
in order to retain the cache (cache contains abs. paths)
- Recommend to add the .serena folder to version control instead
(which will not include the cache folder)
Relates to #805
* Add util function subprocess_util.convert_shell_cmd
* Apply function in
- StdioLanguageServer (replacing use of quote_arg function)
- RuntimeDependencyCollection (previously no quoting applied)
* typescript_vts: add initialization_options pass-through
Extends ls_specific_settings["typescript_vts"] with an optional
initialization_options key — a dict forwarded to vtsls via all three
LSP configuration channels:
- the initialize request (initializationOptions field),
- a workspace/didChangeConfiguration notification right after initialize,
- and responses to workspace/configuration pulls, looked up per section
(e.g. "typescript", "vtsls", "javascript", or dotted paths like
"typescript.tsdk").
All three channels are necessary because different parts of vtsls read
settings from different places — notably typescript.tsdk, which vtsls
pulls via workspace/configuration rather than reading from
initializationOptions. Without the pull-answer, setting tsdk had no
effect.
Primary use case: Yarn Plug'n'Play projects. Running
`yarn dlx @yarnpkg/sdks vscode` in the project root generates
.yarn/sdks/typescript/lib/tsserver.js, a PnP-aware tsserver. The user
then points vtsls at it with:
ls_specific_settings:
typescript_vts:
initialization_options:
typescript:
tsdk: "<...>/.yarn/sdks/typescript/lib"
vtsls:
autoUseWorkspaceTsdk: true
autoUseWorkspaceTsdk is required alongside tsdk because, in a headless
LSP context, there is no UI prompt to confirm switching to the
workspace TypeScript version. See yioneko/vtsls#169 for the recipe.
Default behaviour is unchanged — the field is optional, omitted from
the initialize params and didChangeConfiguration when unset or empty,
and workspace/configuration continues to answer empty sections.
Add structured non-source file types (.yaml, .json, .toml, .graphql,
.proto, .sql, .tf, .hcl, etc.) to the read-file nudge set.
These extensions are common in real-world projects and repeated raw
reads of them are equally well served by `search_for_pattern` or
other Serena tools — the same rationale that applies to .py/.ts already
applies to config, schema, and query files.
Note added to the docstring: `search_for_pattern` works regardless of
extension and is always a valid alternative to repeated raw reads.
