Plugin marker hooks follow the shell's cwd, so a `cd` mid-session marks the wrong repository

[max-sixty]

The six marker hooks in plugins/worktrunk/hooks/hooks.json — marker set on
UserPromptSubmit, Notification, PreToolUse, PermissionRequest and Stop,
and marker clear on SessionEnd — run without -C:

bash "$CLAUDE_PLUGIN_ROOT/hooks/wt.sh" config state marker set 💬 || true

So the marker resolves against the hook process's working directory. That is the
agent's shell cwd, and an agent moves it during a turn — reading files out of a
second checkout, for instance. The two hooks in the same file that do reach for a
directory both scope it: WorktreeRemove passes -C "$p", and WorktreeCreate
cds to CLAUDE_PROJECT_DIR.

Three consequences, all silent:

• A cd into another repository marks that repository's branch instead, and the
  session's own marker stops updating. The statusline then carries a stale
  marker on the branch being worked on and a spurious one somewhere else.
• A session that ends while the shell sits in another repository clears that
  repository's marker on SessionEnd, and leaves its own set.
• In a directory that is not a repository the command prints
  ✗ git rev-parse --git-common-dir failed (exit 128) and exits 1. The trailing
  || true turns that into a success, so nothing surfaces.

Repro, given a worktree of one repo and any second repo:

cd /tmp/repo-a.feature && wt config state marker set 🧪
# ✓ Set marker for feature to 🧪

cd /tmp/repo-b && wt config state marker set 🧪
# ✓ Set marker for main to 🧪      <- repo-b's branch, from a session on `feature`

cd /tmp/not-a-repo && wt config state marker set 🧪
# ✗ git rev-parse --git-common-dir failed (exit 128), rc 1

The marker should track the worktree the session belongs to rather than wherever
its shell currently is. -C <path> would carry that, but the value to pass isn't
obvious: CLAUDE_PROJECT_DIR is the launch directory and goes stale once the
session moves to another worktree mid-run, and the hook payload's cwd is the
same directory that drifted. Pinning the worktree at session start is one route;
resolving it from the session record is another.

Seen on worktrunk e4238e8.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

Heads-up that this issue never got triaged: the tend-triage run for it (32985839479) hit a startup_failure and ran zero steps, so nothing here is a judgement on the report — the bot simply never saw it. Today's review-runs sweep turned it up from the run census.

tend-triage fires only on issues: opened, so there is no automatic second attempt; an @worktrunk-bot mention on this thread is the way to summon a look. I've filed max-sixty/tend#1066 upstream so a run that dies before the failure handler stops being invisible to that sweep.

[worktrunk-bot]

Triage that the stranded run never did. Two findings: the premise checks out against upstream's own spec, and the scope is wider than one file.

The unscoped shape is in three of four plugins, not one

plugins/worktrunk/hooks/hooks.json is where you found it, but the same bare invocation ships in every plugin except OpenCode — 13 sites total:

Plugin	File	Unscoped marker calls
Claude Code	plugins/worktrunk/hooks/hooks.json	6
Codex	plugins/worktrunk/.codex-plugin/plugin.json	4
Gemini CLI	hooks/hooks.json	3
OpenCode	dev/opencode-plugin.ts	0 — already pinned

OpenCode is the interesting row. It pins every call with .cwd(directory), and its comment already states this bug class as the reason: "is load-bearing: it pins the command to the directory this plugin instance was created for. Without it, the command runs in whatever the process-wide cwd happens to be at spawn time." So the diagnosis was already reached once, for one host, and the other three didn't get it.

Upstream confirms both halves of "the value to pass isn't obvious"

Your paragraph ruling out both candidates is right, and it's documented behavior rather than an accident — worth knowing because it means neither is going to change under us:

• CLAUDE_PROJECT_DIR really does go stale. The hooks reference states it directly for the worktree case: "${CLAUDE_PROJECT_DIR} stays put: it still points at the project root where the session started."
• The payload cwd is the drifted value, so reading it buys nothing. "cwd follows Claude: the cwd field in the hook's input JSON is the worktree root after Claude enters a worktree, and the new directory after Claude runs cd." And handlers "run in the current directory" — so the payload field and the process cwd are the same value. -C "$(jq -r .cwd)" would formalize the drift, not fix it.

This is also why OpenCode's fix isn't portable. directory is a value the OpenCode host hands the plugin at instance creation — session-pinned, from the host. Claude Code, Codex, and Gemini expose no equivalent: the payload carries session_id, transcript_path, cwd, permission_mode, hook_event_name, and no worktree identity at all. So "pinning the worktree at session start", the route you name, would have to be worktrunk storing its own session_id → worktree mapping, not just passing a variable through.

That leaves a real product question I don't think triage should pick for you: when a session legitimately enters a worktree mid-run, should the marker follow it? Launch-pinning says no and makes the reported bug disappear; following-on-entry says yes and needs the mapping above to tell a worktree entry apart from a cd to go read a file.

No PR

The failing transition fires inside a live agent session, which CI can't drive — per the repo's own bar for this, a fix premised on it would ship unverified. The three consequences you list are also unaffected by which target gets chosen except the third: the non-repo exit 1 swallowed by || true is wrong under every option, since a hook that can't find a repo should be a no-op rather than a suppressed failure.

Sources and verification notes

Codebase claims checked at 03ae3b6f60abff4b67f4bb916862c3c656d59282.

• Site count from grep -rn "marker set\|marker clear" across tracked files, excluding docs, snapshots, and src/**.rs. The Claude Code file's 6 are UserPromptSubmit, Notification, PreToolUse(AskUserQuestion), PermissionRequest, Stop, SessionEnd; Codex has 4 (no Notification, no PreToolUse); Gemini has 3 (BeforeAgent, AfterAgent, SessionEnd).
• -C <path> confirmed as a global flag — src/cli/mod.rs#L257-L263. The contrast you noted holds: WorktreeRemove passes -C "$p" and WorktreeCreate cds to CLAUDE_PROJECT_DIR; the marker hooks pass nothing.
• Upstream quotes are from the Claude Code hooks reference (https://code.claude.com/docs/en/hooks.md), fetched 2026-08-28: the worktree note under "Reference scripts by path", the "Handlers run in the current directory" line, and the "Common input fields" table. Field list above is that table verbatim, minus fields marked subagent-only.
• Not verified: that a cd mid-session actually relocates the hook process in a running Claude Code session. The two documented facts compose to it, but this session has no agent CLI to observe it in — which is the reason there's no PR here rather than a fix.