bug(hooks): genie-hook native client emits wrong [from:] attribution — orchestrator name leaks (#1485 followup)

[namastex888]

Summary

Followup to #1485. The compiled genie-hook thin client is supposed to honor GENIE_AGENT_NAME from its environment when forwarding the hook to the daemon, so the eventual SendMessage (and other identity-bearing hooks) shows [from:<actual-agent>]. Instead, every dispatched hook is attributed to [from:genie] (the orchestrator), regardless of the env the client was invoked with.

Repro (per dog-fooder-11eb verdict, 2026-04-29)

cd /home/genie/workspace/repos/genie/.worktrees/dogfood-session
bun run build && bun link
genie serve start --daemon --headless
bun build --compile src/hooks/dispatch-client.ts --outfile dist/genie-hook
printf '%s' '{"hook_event_name":"PreToolUse","tool_name":"SendMessage","tool_input":{"recipient":"genie","message":"identity probe"},"session_id":"dogfood-env-probe"}' \
  | GENIE_AGENT_NAME=dogfood-env-probe GENIE_TEAM=genie dist/genie-hook

# Expected: [from:dogfood-env-probe]
# Actual:   [from:genie]

Evidence: /home/genie/workspace/agents/genie/.genie/agents/dog-fooder/state/evidence/batch-2034c4f3

Why this is a release-blocker

Every SendMessage from a daemon-mode hook would attribute the message to whichever agent owns the daemon process (typically genie), not the actual sender. That breaks identity-based routing, scope-validation, and audit trails. End-users would see all messages appearing to come from one source.

Acceptance

• Compiled genie-hook reads GENIE_AGENT_NAME from process.env and forwards it through the UDS frame
• Daemon-side dispatcher honors the forwarded name when stamping [from:] on outgoing identity-bearing hooks
• Repro above produces [from:dogfood-env-probe] end-to-end

[namastex888]

Fix design (consolidated from now-closed #1504)

dog-fooder-11eb pinpointed the architectural leak in 2026-04-29 verdict: dispatch-client sends only raw hook JSON over UDS; hook-socket calls dispatch(stdin); identity-inject reads daemon process.env.

Required design (multi-file)

1. src/hooks/dispatch-client.ts — extend the UDS frame to include caller env (GENIE_AGENT_NAME, GENIE_TEAM). Either as a JSON envelope wrapping the hook payload or as additional _genieEnv fields injected into the payload object.
2. src/serve/hook-socket.ts — parse the envelope/extra fields out of the frame before calling dispatch(). Stuff into an AsyncLocalStorage<RequestContext>.
3. src/hooks/index.ts — runHandler() resolves identity from the AsyncLocalStorage context (fall back to process.env for legacy F1-fork callers).
4. src/hooks/handlers/identity-inject.ts — read from request context, not process.env.
5. src/hooks/handlers/runtime-emit.ts (and other telemetry emitters) — same.

Why not a one-line fix

Hooks have multiple concurrent dispatchers in flight at any given moment in daemon-mode. Mutating process.env for the duration of one dispatch races every other in-flight one. AsyncLocalStorage is the correct primitive (Node native).

Backward compat

Legacy F1-fork callers (when hook.sock is missing) fork bun with their own process.env set — no daemon multiplexing, so process.env IS correct for that path. The fix should:

• prefer AsyncLocalStorage when present
• fall back to process.env when AsyncLocalStorage is empty (legacy path)

Effort

~120 lines across 5 files, plus tests for the AsyncLocalStorage thread-through. Solo-developer ~3-4 hours including dogfood verification.

Evidence: /home/genie/workspace/agents/genie/.genie/agents/dog-fooder/state/evidence/followups-1490-1491-1493/REPORT.md

[namastex888]

Triage @ 2026-04-30 — STILL-OPEN-CONFIRMED

Tested against: chore/pgserve-2.0.2 HEAD 4b5e1820 (chore(version): bump to 4.260429.33 [auto-version])

Evidence — the AsyncLocalStorage refactor described in the issue is not in tree:

• src/hooks/dispatch-client.ts — no _genieEnv envelope, no GENIE_AGENT_NAME/GENIE_TEAM field added to the UDS frame. Frame is still raw hook payload.
• src/serve/hook-socket.ts — no AsyncLocalStorage, no RequestContext. Calls dispatch(stdin) with no caller-env context.
• src/hooks/index.ts — no AsyncLocalStorage, no RequestContext.
• src/hooks/handlers/identity-inject.ts:22 — still reads process.env.GENIE_AGENT_NAME directly:

  const agentName = process.env.GENIE_AGENT_NAME;

• src/hooks/handlers/runtime-emit.ts:246 — same pattern: agent_id: process.env.GENIE_AGENT_NAME ?? null.
• Repo-wide grep: git grep -l 'AsyncLocalStorage' chore/pgserve-2.0.2 -- src/hooks/ src/serve/ returns no matches.
• No commits since the issue was filed touch this design surface (git log --grep=1491 since 30 days returns nothing; recent hook work — 63b2aa14, b0587444, cf7275fd, f9be3c4c — addresses the bun-fork hot path, stdout draining, postinstall binary compilation, and test isolation, none of which thread caller identity through the daemon).

Verdict: STILL-OPEN-CONFIRMED — daemon-multiplex process.env race remains. The 5-file design from the dog-fooder report is still the right fix and still unimplemented.