fix(hooks): sessionStart/sessionEnd hooks fire from bridge CWD, not session workingDirectory

[raykao]

Summary

onSessionStart (and other hooks that fire from the CLI subprocess) execute relative to the bridge process CWD, not the per-session workingDirectory passed to createSession.

Root Cause

CopilotBridge constructs CopilotClient once at startup with no cwd option:

// src/core/bridge.ts
this.client = new CopilotClient({
  autoStart: true,
  telemetry: options?.telemetry,
  env: options?.env,
  // no cwd: option
});

The SDK defaults cwd to process.cwd() (the bridge's launch directory):

// @github/copilot-sdk dist/client.js
cwd: options.cwd ?? process.cwd(),

The CLI subprocess is spawned once from that fixed CWD. workingDirectory is passed as a per-session RPC config, but the CLI process itself was already started from the bridge's launch directory.

Impact

Hook scripts are loaded correctly by the bridge's Node-side loadHooks(workingDirectory) (for preToolUse etc. which the bridge calls directly). But sessionStart/sessionEnd hooks are fired by the CLI subprocess via hooks.invoke RPC - that subprocess resolves hook paths relative to its own CWD, not the session's workingDirectory.

Result: workspace-scoped sessionStart hooks silently do nothing for sessions whose workingDirectory differs from the bridge's launch directory.

Affected hooks

• sessionStart
• sessionEnd
• errorOccurred

Hooks dispatched directly by the bridge Node process (preToolUse, postToolUse, userPromptSubmitted) are unaffected because the bridge loads those scripts explicitly from workingDirectory before passing them to the SDK.

Expected behavior

The CLI subprocess should be spawned (or re-spawned) with the session's workingDirectory as its CWD, OR the SDK should support passing a per-session workingDirectory override for hook resolution.

Steps to reproduce

1. Start the bridge from directory A
2. Create a session with workingDirectory set to directory B
3. Place a sessionStart hook in B/.github/hooks/hooks.json
4. Hook does not fire

[raykao]

Update (2026-05-26) - Prior analysis was incorrect

After deeper investigation, the original root cause analysis in this issue is wrong. Closing the original framing and replacing with accurate findings.

What we got wrong

The claim that "CLI subprocess resolves hook paths relative to its own CWD" is incorrect. Hook execution is entirely Node-side in the bridge - the CLI subprocess's CWD is irrelevant to hook script execution.

The actual flow:

1. loadHooks(workingDirectory) in hooks-loader.ts - bridge Node process discovers hooks.json from the session's workingDirectory
2. executeHookCommand in hooks-loader.ts - bridge Node process spawns bash with cwd = baseDir (directory containing hooks.json), not the CLI subprocess CWD
3. CLI subprocess fires hooks.invoke RPC as a trigger only - it contains hookType and input data, but the actual bash script is run by the bridge Node process with the correct workspace CWD

The CopilotClient cwd option affects where the CLI binary subprocess is launched from - it does not affect hook script execution paths.

Real open question

If sessionStart hooks are not firing in practice, the question is:

Does the Copilot CLI actually send hooks.invoke with hookType: "sessionStart" when the hooks: true capability is advertised in session config?

The bridge SDK is correctly wired to handle it (_handleHooksInvoke dispatches to the registered handler). But if the CLI binary does not send the RPC for sessionStart, nothing fires regardless of bridge code.

This is a CLI binary behavior question - not something observable or fixable from the bridge side.

Status

No code change needed on the bridge side for hook execution CWD. Leaving this open as a tracking issue for the CLI sessionStart RPC behavior question. If confirmed that the CLI does send hooks.invoke for sessionStart and hooks still don't fire, please reopen with a reproduction case.