Standalone .github/hooks/*.json postToolUse hook never fires (repo-root, non-plugin)

[xaviervv]

Describe the bug

A postToolUse hook defined in a standalone, repo-root .github/hooks/*.json file (not shipped as part of a plugin) never fires. This isn't a config error being silently dropped in the way #3872 describes -- the debug log shows no trace of the hook file being discovered or read at all, not even a rejection.

This is adjacent to several existing reports but distinct from each:

• sessionStart hook in .github/hooks/ does not fire in Copilot CLI (v0.0.420) #1730 covers sessionStart specifically, not postToolUse.
• Plugin-defined preToolUse hooks (hooks.json) do not fire - neither in main session nor subagents #2540 and CLI cannot execute hooks shipped with plugins #3659 cover hooks shipped inside a plugin's hooks.json, not a standalone repo-root .github/hooks/*.json file.
• Hook config with a mis-cased event key (e.g. PreToolUse) is silently dropped — only a debug-level log, no visible warning #3872 covers a mis-cased event key being silently dropped after being read; our config used the correct camelCase postToolUse key per the documented schema, and the loader appears to never reach it at all.
• .claude/settings.json hooks fail on Windows: executed via PowerShell (not bash) and $CLAUDE_PROJECT_DIR not set #4001 is a related but distinct symptom on the separate .claude/settings.json hook-consumption path (wrong shell, missing env var) -- in our own testing, Copilot CLI didn't attempt to run that hook either, rather than running it incorrectly.

Affected version

@github/copilot (npm) 1.0.80, Windows 11 (see note below on an inconclusive Linux attempt).

Steps to reproduce the behavior

1. In a git repo, create .github/hooks/validate-dockerfile.json:

   {
     "version": 1,
     "hooks": {
       "postToolUse": [
         { "type": "command", "bash": "path/to/shared-script.sh", "powershell": "path/to/shared-script.ps1", "cwd": ".", "timeoutSec": 30 }
       ]
     }
   }

   (shape taken directly from the documented schema at https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-hooks)
2. The referenced script is instrumented to append its real invocation (stdin, argv, cwd, env) to a log file, so firing can be verified directly rather than inferred.
3. Start a non-interactive session (copilot -p --allow-all-tools "edit the Dockerfile to add one line") that edits a file matching a tool call the hook should intercept.
4. The edit succeeds. The log file is never created -- the hook script is never invoked.

Repeated across 4 independent variations on Windows, all with the same result (hook never fires):

• Baseline config as above, no matcher field.
• Same, with --experimental passed at launch.
• Same, with an explicit "matcher": "*" field added (in case an absent matcher means "match nothing" rather than "match everything").
• Same, but the triggering edit made via the Write tool (creating the file) instead of Edit (modifying an existing file), to rule out a tool-specific gap.

~/.copilot/logs/process-*.log for the Windows runs shows a NativeHookPipelineProcessor registered for postToolExecution in general, but contains zero references to validate-dockerfile.json, .github/hooks, or any hook-discovery trace for the test repo -- consistent with the hook file never being read, not merely filtered out after being read (which is what #3872's fix would surface as a debug-level "ignoring unknown event" line; no such line appears here either).

A Linux (WSL2 Ubuntu, same 1.0.80) attempt was made but is inconclusive, not confirmatory -- npx @github/copilot was genuinely invoked, but no ~/.copilot/logs/process-*.log was produced at all, so it can't be distinguished from the session simply not reaching the test step. Not claiming cross-platform confirmation until this is re-verified with the same log-level rigor as the Windows finding above.

Expected behavior

A postToolUse hook in a standalone repo-root .github/hooks/*.json file, using the documented schema, should fire on a matching tool call -- the same way it does for Claude Code's equivalent PostToolUse hook in .claude/settings.json, which was verified firing correctly in the same test session as a control.

Additional context

• Found while verifying whether a single validator script could be shared across a Claude Code PostToolUse hook and a Copilot CLI postToolUse hook, for a cross-tool developer tooling project.
• Windows-specificity not yet ruled out -- see the inconclusive Linux note above.
• This report was drafted with AI assistance (Claude Code) based on a live, instrumented reproduction; happy to provide the raw log files or test fixtures if useful for triage.

[xaviervv]

Update: reproduced the same non-firing behavior on Linux (WSL2 Ubuntu, same 1.0.80) -- two independent attempts (baseline config, and with an explicit "matcher": "*"), both resulted in the hook script's invocation log never being created. Confirms this isn't Windows-specific. Issue body updated with the details.

[xaviervv]

Correction to my update above: on closer verification, I overstated confidence in the Linux reproduction. What I can actually confirm: npx @github/copilot@1.0.80 was genuinely invoked in a Linux (WSL2 Ubuntu) environment. What I cannot confirm from available evidence: that a complete non-interactive session actually ran to the point of attempting the file-edit tool call that should trigger the hook -- the Linux-side ~/.copilot/logs/ is empty (no process-*.log at all), which is equally consistent with "the hook didn't fire" and with "the session didn't get that far" (e.g. auth/network issue). I don't have enough information to distinguish those.

Walking back the "confirmed not Windows-specific" claim until this is verified properly with the same log-level rigor as the original Windows report (a complete process log showing the session ran normally but the hook-discovery trace is absent, not just an empty log directory). Original Windows-only finding (4 independent attempts, full process-log detail) stands as reported.