Agent integration: activity tracking for GitHub Copilot CLI

[AsafMah]

Context

I'm using worktrunk alongside GitHub Copilot CLI for parallel agent work in a repo with ~11 worktrees. The CLI itself works great — wt list was exactly what I needed to survey branch / dirty state / ahead-behind / age in one shot and pick an idle worktree.

The gap

wt config plugins offers claude, codex, opencode (plus Gemini via gemini extensions). There's no Copilot CLI option, so the activity tracking markers (🤖 / 💬 in wt list) aren't available.

That's the capability I'd value most. "Which worktree already has an agent in it?" is the question I actually needed answered, and without markers there's no good signal — file mtimes are useless (running git status across candidates updates the very timestamps you're sampling), and commit age only tells you when someone last committed, not whether a session is live right now.

I searched the issue tracker and didn't find an existing request or workaround for Copilot CLI, so filing in case it's useful signal.

What already works

The marker mechanism itself is agent-agnostic — it's just git config underneath:

wt config state marker set "🤖"
wt config state marker set "🤖" --branch <branch>
wt config state marker clear
git config worktrunk.state.<branch>.marker '{"marker":"💬","set_at":0}'

So this is usable today by convention: set on entry, clear on exit. The only missing piece is session lifecycle, not the marker plumbing.

Ask

Either would solve it, and the first is much cheaper:

1. Document a "generic agent" integration — a short section stating that any CLI can participate by calling marker set / marker clear around a session, with the stale-marker caveat you already note. That would make the manual pattern a supported one rather than something users reverse-engineer from the manual-markers section.
2. A Copilot CLI plugin, if its hook surface exposes something equivalent to Codex's Stop / SessionEnd. I'm honestly not sure it does — I haven't confirmed what's available there — so I'd treat (1) as the realistic ask and (2) as a maybe.

Happy to test either. Not blocking anything for me; the manual convention is fine.

Environment: wt v0.74.0, Windows.

[worktrunk-bot]

Thanks — this is a well-scoped report, and the answer to the part you flagged as uncertain is better than you guessed.

Copilot CLI does have the hook surface for (2). It exposes sessionStart, userPromptSubmitted, agentStop, and sessionEnd, and — the piece that matters for a plugin — hooks can be configured user-level, at ~/.copilot/hooks/*.json (%USERPROFILE%\.copilot\hooks\ on Windows), not just per-repo. That's everything the Codex target uses, plus a real turn-boundary event, so the full 🤖/💬 alternation maps rather than just "session is live". Hooks reference.

For (1), I've opened #3848 — a new Agent CLIs without a plugin section under Activity tracking, stating the three-call contract and the three things that bite: the command resolves the branch from its working directory (so the hook must run inside the worktree), marker set exits non-zero outside a repository so it needs guarding, and every set needs a pairing clear. That makes the pattern supported for any host, which also covers #3571 (pi / oh-my-pi) — the same gap from a different CLI.

Config to try today. Since you offered to test — this follows GitHub's documented schema but I have no way to drive a Copilot session from CI, so it's unverified. At ~/.copilot/hooks/worktrunk.json:

{
  "version": 1,
  "hooks": {
    "sessionStart": [
      { "type": "command", "bash": "wt config state marker set \"🤖\" || true", "powershell": "wt config state marker set \"🤖\"; exit 0" }
    ],
    "userPromptSubmitted": [
      { "type": "command", "bash": "wt config state marker set \"🤖\" || true", "powershell": "wt config state marker set \"🤖\"; exit 0" }
    ],
    "agentStop": [
      { "type": "command", "bash": "wt config state marker set \"💬\" || true", "powershell": "wt config state marker set \"💬\"; exit 0" }
    ],
    "sessionEnd": [
      { "type": "command", "bash": "wt config state marker clear || true", "powershell": "wt config state marker clear; exit 0" }
    ]
  }
}

The one thing worth watching: hooks default to running at the repository root, which is the worktree root when you started the session inside a worktree — but if a marker lands on the wrong branch, that's the cause, and the cwd field on each hook entry (or --branch) is the lever. If you confirm it works, adding it to #3848 as a worked example is a natural follow-up, and it would be good evidence for a native wt config plugins copilot target — that call is @max-sixty's; #3594 is the adjacent in-flight work for pi.

Sources and notes

• Copilot CLI hook events, user-level ~/.copilot/hooks/*.json load path, the {version, hooks: {event: [{type, bash, powershell, cwd, timeoutSec}]}} schema, and exit-code semantics (non-preToolUse events fail open): hooks reference. Feature Request: Global Hooks Configuration with UserPromptSubmit, Stop, and Notification Events github/copilot-cli#1157, which asked for global hooks and lifecycle events, is closed — the surface it requested now exists.
• Marker behavior verified locally against a scratch repo with a linked worktree: marker set resolves the branch from cwd and works from a subdirectory; outside a repository it exits 1 (git rev-parse --git-common-dir failed), which is why the hooks above are guarded; marker clear with no marker set exits 0, so it's safe to run unconditionally on session end.
• Existing precedent for the event→command mapping: dev/opencode-plugin.ts.

A maintainer will weigh whether a native Copilot target is worth adding.