Files
serena/docs/02-usage/999_additional-usage.md
T
Tomi P. Hakala b5b9cc4ffc Fix find_project_root hijacking git worktrees nested under a Serena project (#1550)
* 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
2026-06-07 18:05:01 +02:00

1.4 KiB

Additional Usage Pointers

Prompting Strategies

We found that it is often a good idea to spend some time conceptualizing and planning a task before actually implementing it, especially for non-trivial tasks. For very complex tasks, you can make a detailed plan in one session, where Serena may read a lot of your code to build up the context, and then continue with the implementation in another, having persisted the plan in a memory or dedicated file.

Serena and Git Worktrees

git-worktree can be an excellent way to parallelize your work. More on this in Anthropic: Run parallel Claude Code sessions with Git worktrees.

Be sure to add the .serena folder to version control, such that your project-specific settings and memories are available across worktrees.

When you launch a CLI agent from inside a worktree using --project-from-cwd, Serena activates the worktree itself, even if the worktree lives under another Serena project (for example <repo>/.claude/worktrees/<name>, where Claude Code creates them natively). The nearest project boundary wins: the worktree's own .git pointer file takes precedence over an ancestor's .serena/project.yml, so file operations always resolve against the correct working tree.