[timkjr]

What

setupSessionListeners() hands every non-external session's workingDir to the Ralph tracker (session.ralphTracker.setWorkingDir). For a remote-SSH session that directory is a path on the remote host, but RalphFixPlanWatcher reads and fs.watch()es it on the local disk. The Ralph tracker auto-enables on pattern detection, so this runs for remote sessions whether or not the user ever turned Ralph on.

Observed on a server with two remote sessions on another host, once per remote session at every server start:

[RalphFixPlanWatcher] Could not watch @fix_plan.md: Error: ENOENT: no such file or directory, watch '/home/<user>/homelab-infrastructure'

Two side effects beyond the log noise:

• Where a directory with the same path happens to exist locally, the watcher watches (and imports todos from) the wrong tree.
• isFileAuthoritative is _fixPlanPath !== null, so setting a path that can never be read made the fix-plan file "authoritative" for every remote session, which switched off the tracker's output-based todo completion (detectAllTasksComplete / detectTaskCompletion return early).

Fix

One condition next to the existing external-CLI skip in src/web/server.ts:

if (!isExternalCliMode(session.mode) && !session.remote) {
  session.ralphTracker.setWorkingDir(session.workingDir);
}

Every path that wires a session (create, /interactive, /interactive-respawn, /shell, reboot restore) goes through setupSessionListeners(), and restore rehydrates session.remote before it runs, so the one guard covers them all. Docker-case sessions are unchanged: their workingDir is the host-side workspace, which is local.

Tests

test/ralph-fix-plan-remote.test.ts drives the real WebServer.setupSessionListeners() (same pattern as discard-partially-built-session.test.ts):

• a remote session: the tracker is never given the directory, nothing logs Could not watch @fix_plan.md, and isFileAuthoritative stays false (fails on master: the remote path is passed to setWorkingDir);
• a local session: still gets its directory.

npm run typecheck, lint, format:check and the full npm test pass locally.

Not covered here (same root cause, left for separate PRs if wanted)

These also treat a remote session's workingDir as a local path:

• POST /api/sessions/:id/fix-plan/write and GET .../fix-plan/read (ralph-routes.ts) read and write @fix_plan.md on the local disk;
• imageWatcher.watchSession(session.id, session.workingDir) a few lines below the fix (quiet, because chokidar waits on a missing path, but it would report local files if the same path exists locally).

🤖 Generated with Claude Code

[Ark0N]

Thank you @timkjr, and welcome! This PR stops the Ralph tracker from pointing its @fix_plan.md watcher at a remote SSH session's working directory, which is a path on the remote host that was being read and watched on the local disk.

I checked every path that wires a session (create, /interactive, /interactive-respawn, respawn, Ralph start, reboot restore, scheduled runs and boot recovery): they all go through setupSessionListeners(), and Session.remote is set in the constructor, so the one guard covers them all. Leaving Docker sessions alone is right, since their workspace is bind-mounted at the same path. I also ran your test against master's server.ts: it fails there and passes with the fix, so it is a real regression test.

Nothing needs to change on your side. The only touches at merge time are a one-line docs note that the @fix_plan.md auto-load does not run for remote sessions, and rewrapping the header comment line at test/ralph-fix-plan-remote.test.ts:12.

The two follow-ups you listed (the fix-plan/write and fix-plan/read routes in ralph-routes.ts, and imageWatcher.watchSession in setupSessionListeners()) have the same root cause, and a separate PR for either one is welcome. Thanks again for the careful write-up.

[Ark0N]

Merged in 1.47.0 (https://github.com/Ark0N/Codeman/releases/tag/codeman%401.47.0). Thank you for tracking this down from a real log line. At merge I added the note to docs/remote-sessions.md and rewrapped the test header (74fc3ea). The release review changed one thing on top (1ad9db7, ca0f891): a remote session now RECORDS its path through a new setRemoteWorkingDir() instead of getting none, so isFileAuthoritative stays true for it. That flag is true for every local session with a working directory, so the output-based guessers are off there; leaving it false for remote sessions alone would have let a prose line like "All tasks completed" mark every todo done and end a remote loop when it cannot end a local one. Nothing is read or watched on the local disk for a remote session (the watcher refuses both in remote mode), and your test now pins the authority, the guessers staying off, and a same-named local @fix_plan.md never being imported. Whether those guessers should run at all is a fair question for a separate change, for local and remote sessions together.