fix: pass project cwd to mgrep watch subprocess

[mostrub]

Problem

When Claude Code starts a session, the SessionStart hook launches mgrep watch as a background process. The hook reads cwd from the hook payload — the project directory Claude was opened in — but never passes it to subprocess.Popen. The watcher inherits the working directory of the hook runner instead, which is typically the home directory. It immediately hits the home-directory guard and exits with "Cannot watch home directory or any parent directory." The watcher never starts, and because the failure is silent, it looks like mgrep simply is not indexing anything.

Root cause

In mgrep_watch.py, payload.get("cwd") is called and assigned to cwd, but that value is never used. The subprocess.Popen call has no cwd argument, so Python falls back to os.getcwd() at the time the hook runs — not the project directory.

Fix

Pass cwd=cwd to subprocess.Popen. One argument, no other behaviour changes.

I also removed the debug_log(f"All environment variables: {os.environ}") line. It was writing the full process environment to a file under /tmp on every session start. That includes anything sensitive in the environment — API keys, tokens, whatever the user has set. It is not something that should be sitting in a world-readable temp directory, and it was not adding anything useful once the actual bug was fixed.

Testing

Tested on macOS 15 with Claude Code and the mgrep plugin installed. Before the fix, every session start produced the home-directory error in the watcher log. After the fix, the watcher starts in the correct project directory and the initial sync completes. Verified against a project with 223 files — all indexed cleanly on first run.

---

Note

Low Risk
Low risk change limited to the SessionStart hook: it only adjusts the working directory used to launch mgrep watch and removes overly-verbose/sensitive debug logging.

Overview
Fixes mgrep watch startup by launching the watcher subprocess with cwd from the hook payload so it runs in the project directory instead of the hook runner’s default directory.

Also tightens logging by writing watcher stdout/stderr to a single per-session log file and removing the debug line that dumped all environment variables to disk under /tmp.

^{Written by Cursor Bugbot for commit 0f22366. This will update automatically on new commits. Configure here.}

[Copilot]

Pull request overview

This PR fixes mgrep watch startup in the SessionStart hook by ensuring the watcher subprocess runs from the actual project directory rather than inheriting the hook runner’s working directory (often ~/), which can cause watch initialization failures.

Changes:

• Pass cwd from the hook payload into the subprocess.Popen(["mgrep", "watch"], ...) invocation.
• Add a debug log line indicating which working directory the watcher is being started in.
• Consolidate watcher stdout/stderr into a single session-scoped log file handle.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

cwd is taken from the hook payload and passed directly to subprocess.Popen. If the payload is missing/invalid or cwd is None/not a directory, this will either crash earlier (payload.get) or raise in Popen, making the hook fail in a hard-to-diagnose way. Consider validating payload and cwd (non-empty, exists, is a directory) and exiting with a clear debug log if it’s not usable.

[Copilot]

session_id from the hook payload is interpolated into the log filename. If session_id contains path separators or .., this could write/overwrite unexpected paths under /tmp (or just produce invalid filenames). Consider sanitizing session_id to a safe character set or generating the filename via tempfile/a UUID, while still including the session id in the file contents for correlation.

[Copilot]

The log file handle is opened and then the script continues (and exits) without explicitly closing it. Although the OS will close it on process exit, using a context manager (or explicitly closing after Popen) avoids reliance on interpreter shutdown semantics and ensures the FD isn’t kept open if this script ever grows to do more work.