bug: LSP router derives subprocess working directory from daemon launch cwd, not the tracked repo path (multi-repo daemon)

[conradcoffman]

Title

bug: LSP router derives subprocess working directory from daemon launch cwd, not the tracked repo path (multi-repo daemon)

Version

v0.60.0+dd3bb30 (Windows amd64)

Summary

In a daemon tracking multiple repos, when an LSP-based semantic provider (e.g. omnisharp) is enabled via .gortex.yaml for one of the tracked repos, the LSP router fails to start that server with a chdir error. The working directory it tries to chdir into is built from the daemon process's own launch-time current working directory, not the path of the repo the LSP server is actually being started for — producing a nonexistent path whenever the daemon wasn't launched from inside that specific repo.

Reproduction

1. Track two or more repos with the daemon, e.g.:

   gortex track C:\dev\repoA
   gortex track C:\dev\repoB
   

2. Enable an LSP-based semantic provider for one of them in that repo's .gortex.yaml:

   semantic:
     enabled: true
     mode: typecheck
     providers:
       - name: omnisharp
         enabled: true

3. Start the daemon from a directory that is not repoB — e.g. the user's home directory:

   cd C:\Users\someuser
   gortex daemon start --detach
   

4. Run any query against repoB that needs semantic/LSP enrichment (e.g. gortex query callers ...).

Observed

The daemon log shows the LSP server failing to start with a malformed working directory — the daemon's own launch cwd joined with a repo-relative path fragment:

{"level":"warn","msg":"LSP server failed to start; skipping its language enrichment this session","spec":"omnisharp","error":"start omnisharp: chdir C:\\Users\\someuser\\SomeProject\\SomeFolder: The system cannot find the path specified."}

C:\Users\someuser is where the daemon happened to be launched from — not repoB's actual path (C:\dev\repoB). SomeProject\SomeFolder is a repo-relative path fragment from the query, seemingly joined directly onto the daemon's cwd instead of being resolved against the tracked repo's root.

Workaround found

Restarting the daemon with its cwd explicitly set inside the specific repo that needs LSP enrichment works around it — the LSP server then starts and completes its restore/init correctly for that one repo. This isn't a viable general solution for a daemon tracking multiple repos that each need their own LSP-based enrichment, since only one repo's path can be the daemon's cwd at a time.

Expected behavior

The LSP subprocess's working directory should be derived from the tracked repo's own path (as recorded when it was tracked), independent of whatever directory the daemon process itself happened to be launched from.

Additional notes

• No crash, no AV/security-tool interaction — the daemon and the LSP server (OmniSharp, in my case) both continue running; only that one language's enrichment silently no-ops for that session, logged as a warning rather than surfaced anywhere in CLI output.
• Happy to share the full daemon log excerpt or test further if useful — kept repo/path names out of this report since the test repos aren't public.