feat(daemon): attest human presence to LORE for the Codex path (lr-f7c100)

[clagentic-builder]

What changed

On a Codex session driven by a human through the console, the console now calls LOREs platform-agnostic human-presence declarer: lore session attest-human SESSION_ID, keyed on the Codex thread/rollout id, the moment that id first becomes known.

Why

LOREs engram-mint gate is default-deny on a positive human-presence attestation (lore lr-6b2f6e). Claude console (SDK) sessions are already covered by LOREs own pulse hook (PR 1897): Claude Codes Stop-hook lifecycle fires for an SDK-driven query exactly as it does for the claude CLI; verified live on this very session (its sidecar carries source=hook, and lore engram list shows it already scribed). Codex has no equivalent hook: the console drives Codex directly over the app-server JSON-RPC protocol, so 29 of 31 substantive Codex rollouts on this host since 2026-09-01 mint no engram (lore lr-37c8cc). This closes that gap from the console side, per lore lr-f7c100 comment 1s explicit scope narrowing (the Claude half may already be satisfied; the half NOT covered is the consoles Codex path).

How

Human-vs-headless distinction is structural, not heuristic. session.humanOriginated is set only inside project-user-message.jss WS message/send_scheduled_now handlers: the ONE code path in this codebase reachable exclusively by a live client turn. Headless session drivers (project-loop.jss Ralph Loop iterations, project-external-trigger.js, scheduler.js) build history and call sdk.startQuery directly from their own functions and never pass through that handler, so they structurally cannot set the flag: a scheduled or autonomous Codex dispatch is never attested. This was confirmed by an explore pass over the session-creation call graph (all sm.createSession/sdk.startQuery call sites enumerated) before writing any code.

Ordering (load-bearing per the tasks acceptance criteria): the attest-human call fires in sdk-message-processor.jss existing _isNewSessionId branch, the moment parsed.sessionId (the Codex thread id, captured from thread/starts result) is first seen, gated on session.vendor being codex and session.humanOriginated being true. This is before any turn completes, i.e. before LOREs sentinel evaluates a dispatch decision for that session id. Demonstrated directly: ran lore session attest-human against a synthetic id with no prior sidecar, confirmed via find that the sidecar did not exist beforehand and does exist immediately after, at the exact path LORE writes to at runtime on this host (/tmp/lore-runtime-0/, discovered via find, not hardcoded from the task descriptions prose).

Fail-open by construction: lib/lore-attestation.js is a new, single-purpose module using execFile with a bounded 5s timeout, fire-and-forget (caller never awaits it), and any failure, including ENOENT when the lore binary is entirely absent, is swallowed after a log line. Session create is never affected on a host without LORE installed.

Claude is deliberately NOT touched. Calling attest-human for Claude too would be harmless but is out of scope per comment 1 and code-craft rule 1 (minimal change for the assignment): the pulse hook already covers it, confirmed live on this session.

Verification (per retro tome 845, demonstrated failure first)

1. Missing-sidecar baseline: confirmed empty via find against /tmp/lore-runtime-0 for a fresh id before invoking anything.
2. Sidecar appears for a human-attested id: ran the real lore session attest-human CLI call (the exact command lib/lore-attestation.js invokes) and confirmed the sidecar exists on disk immediately after, with interactive=true and source=manual.
3. Sidecar does NOT appear for a headless id: confirmed no sidecar exists for the id used in the headless Codex session is NEVER attested regression test, corroborating that the mocked assertion matches real on-disk behavior.
4. Full regression coverage in test/sdk-message-processor-codex-human-attestation-lr-f7c100.test.js (4 tests: human-driven Codex attested; headless Codex never attested; human-driven Claude NOT attested here, pulse hooks job; attested exactly once per session, not per turn) and test/lore-attestation-lr-f7c100.test.js (2 tests: fail-open on missing binary; no-op on falsy/non-string session id).

Test status

npm test: 1609 of 1609 passing (6 new).

TASK: lr-f7c100

Update: CI-red fix folded in

Coordinator/NAOMI reported PR 421 CI RED at head 73b3286 (check-test-count FAIL, named test failure, pull_request check-suite, 56s run). Diagnosed and fixed on this same branch rather than opening a new PR.

DIAGNOSIS: category (a), a bug in this diffs own new test file, not (b) unrelated environment divergence and not (c) the lr-eb0d5e daemon-spawn/waitForServer flake pool.

test/lore-attestation-lr-f7c100.test.js originally mutated the real process.env.PATH to simulate a host without the lore binary, then restored it in a synchronous finally block, before the async execFile call it triggered had actually settled. That is a genuine race: the restore ran before the spawn resolved, so the test never verified the ENOENT branch it claimed to, and left an unawaited child process in flight past the end of the test, exactly the leaked-handle failure class check-test-count.js (lr-795882/lr-a7b03e) exists to catch. This matches PEACHES own finding that the tests should verify real settlement rather than only mocking attestHumanSession.

Ruled out lr-eb0d5e explicitly: none of its four tracked files (shell-asset-public-before-auth-lr-2895ea, ws-subprotocol-echo-cookie-auth-lr-4c58ae, boot-smoke-lr-1a5f, project-asset-auth-fallback-lr-e33776) touch lib/lore-attestation.js, lib/sdk-message-processor.js, lib/project-user-message.js, or process.env.PATH, and that pools signature symptom (daemon did not respond within 20000 ms) is a different harness and a different failure shape than an unmocked async CLI-spawn race in a brand-new unit test file.

FIX: lib/lore-attestation.js gains an optional, test-only onSettled hook on attestHumanSession, invoked once the real execFile callback (or the synchronous invalid-input early return) actually completes. No production call site passes it, so production signature and behavior are unchanged for every existing caller. The test now awaits real completion through this hook and never touches global process.env.PATH, so it is deterministic regardless of whether a real lore binary exists in the test environment, and never leaves a child process unaccounted for.

VERIFICATION: two clean local npm test runs at the original flagged head (73b3286) both passed 1609 of 1609, which is itself consistent with a race that resolves fine on an idle local sandbox but differently under CI process/scheduler timing. After the fix, two more clean local runs also pass 1609 of 1609. I could not pull the CI check-run log directly (loadout-git-host-api is scoped away from AMoS for that read; it is PEACHES/BOBBIE/NAOMI surface), so this diagnosis is built from direct code inspection of the exact hazard PEACHES flagged, not a captured failing-test name from the CI log itself. If CI still shows the same named failure at the new head, that would falsify this diagnosis and needs a different root cause.

TASK: lr-f7c100

[clagentic-reviewer]

PEACHES — Clean (0 blocking findings)

Reviewed commit: 73b3286 (feat/lr-f7c100-codex-human-attestation)

Summary

The implementation is structurally sound. All six verification checks pass:

1. HUMAN/HEADLESS BOUNDARY — VERIFIED

• project-user-message.js is structurally the ONLY path reachable by a live WebSocket message frame
  • Line 374: Comment explicitly documents this design
  • Lines 609-732 in project-loop.js and 121 in project-external-trigger.js show headless drivers call sdk.startQuery directly, never through the WS handler
  • Scheduler.js follows the same pattern (no routing through project-user-message)
• send_scheduled_now handler at line 329 of project-user-message.js correctly sets session.humanOriginated = true (line 335)
  • Task notes: send_scheduled_now sounds scheduler-adjacent — VERIFIED: it fires only on an explicit live WS frame forcing a delayed send, not from scheduler.js itself
• Headless sessions (Ralph Loop iterations, external triggers) never set humanOriginated, so the gate at line 254 of sdk-message-processor.js correctly excludes them

2. ORDERING — VERIFIED

• Attestation call at line 255 (sdk-message-processor.js) fires inside the _isNewSessionId branch (line 239), at the earliest moment a new session id becomes known
• This is the moment a new parsed event carries parsed.sessionId !== session.cliSessionId — before any turn processing, before the WS frame that triggered this event completes
• No scribe dispatch could occur before this point; processSDKMessage is a synchronous loop with attestation as the first action on a new session id

3. FAIL-OPEN CORRECTNESS — VERIFIED

• lore-attestation.js lines 40-56:
  • execFile spawning is synchronous; any ENOENT or runtime error is caught (lines 41-49)
  • Callback-based, fire-and-forget: no promise returned to caller, no awaited path
  • Timeout 5s (line 24) is advisory, never blocks session create
  • No synchronous throw from execFile itself (line 39); defensive try-catch wraps the call (lines 52-56)
  • Unhandled rejection risk is ZERO: no promise is returned or stored

4. IDEMPOTENCE — VERIFIED

• Test at line 159-176 of sdk-message-processor-codex-human-attestation-lr-f7c100.test.js proves attestation fires only once
• The _isNewSessionId gate ensures the call rides the session-id-changed event, not every turn

5. CORRECT SESSION ID — VERIFIED

• Line 255 passes session.cliSessionId, which was set from parsed.sessionId (line 237)
• parsed.sessionId is the Codex thread id per codex.js line 199 (state.threadId = params.thread.id)
• Comment at line 243 explicitly documents the Codex thread/rollout id is the correct key for LORE attestation

6. CLI-ONLY REQUIREMENT — VERIFIED

• Line 40 uses execFile with lore binary — shells the CLI, not an import
• No library import, no SDK path

Scope Note

The task narrowing is correct: Claude sessions are already covered by LORE's pulse hook (PR #1897). This PR scopes to Codex only, which was the uncovered half.

Testing Observation

The unit tests (lore-attestation-lr-f7c100.test.js, sdk-message-processor-codex-human-attestation-lr-f7c100.test.js) are comprehensive for the call-invocation contract but do NOT verify that an actual sidecar file appears on disk. Per retro tome #845, reports success while nothing happened is the dominant failure mode. However, this is a responsibility boundary issue: the console calls the LORE CLI correctly; LORE's own test suite must verify the sidecar is created. The console code cannot reasonably test LORE's file-writing behavior. No blocking issue.

{"reviewer": "peaches", "review_status": "clean", "head_sha": "73b32863a85479fafe7dc2dda067a960ca52dc96", "pr_number": 421}

[clagentic-security]

Audit of lib/lore-attestation.js, lib/project-user-message.js, lib/sdk-message-processor.js, and the two new test files (lr-f7c100). Reviewed base 8302c71..73b3286.

1. Command injection (sessionId): lib/lore-attestation.js:24 uses execFile("lore", ["session","attest-human",sessionId], {timeout:5000}, cb) -- an argument-array form, not a shell string. No exec()/shell interpolation anywhere in the diff. Provenance of sessionId: lib/sdk-message-processor.js:255 passes session.cliSessionId, which was just assigned at line 237 from parsed.sessionId. For the codex vendor that value traces to lib/yoke/adapters/codex.js:199 (state.threadId = params.thread.id / params.threadId), set only from the Codex app-server thread/started JSON-RPC notification over the adapter's own stdio -- a locally spawned trusted subprocess, not a client WS message or PR-content payload. No shape validation (UUID/hex) is applied, but the execFile argv-array form makes shell metacharacter injection moot regardless of the string's shape; the remaining risk is only the identifier LORE keys on, not code execution. No blocking finding here.

2/3. Over-attestation / auth: session.humanOriginated is set only at project-user-message.js:384 (inside the WS {type:"message"} handler, reachable only via a connected client's handleUserMessage dispatch) and :335 (send_scheduled_now, same WS path, requires nowSession.scheduledMessage already set by a prior authenticated schedule_message call). Verified project-loop.js (Ralph Loop iterations/crafting/judge), project-external-trigger.js (file-watcher spawnSession/pushMessageToSession), and scheduler.js (cron-triggered loop registry) all call sdk.startQuery/pushMessage directly on sessions from sm.createSession() and never touch humanOriginated -- headless paths cannot reach the flag. The gate at sdk-message-processor.js:254 (session.vendor==="codex" && session.humanOriginated) is structurally sound given that. WS authentication itself (ws._clagenticUser, set in project-connection.js before handleConnection) is pre-existing infrastructure this PR does not modify or weaken.

4. DoS/idempotence: gated on the pre-existing _isNewSessionId=!session.cliSessionId guard (unmodified by this PR) -- fires attestHumanSession at most once per session lifetime, each execFile bounded by the existing 5s timeout. No unbounded spawn amplification introduced.

5. Unhandled rejection: execFile is callback-based (not a Promise), so there is no promise-rejection surface. The ENOENT and generic-error branches are both handled inside the same callback (lore-attestation.js:27-33), and the synchronous execFile call itself is wrapped in try/catch (:36). No path can throw uncaught or reject unhandled.

6. Fail-open scope: attestHumanSession never touches session.humanOriginated or any other session state -- fire-and-forget, result never awaited, failure only produces a log line. It cannot cause a session to be treated as locally attested when the call failed.

7. Wrong-session-id / silent-success (tome #845 class): session.cliSessionId is assigned at sdk-message-processor.js:237 from parsed.sessionId, and the same value is what gets attested at :255 in the same tick -- no drift window, no stale/local id substituted. Test 1 in test/sdk-message-processor-codex-human-attestation-lr-f7c100.test.js asserts the exact sessionId argument, not just a call count. Test 4 asserts no re-fire on a second event carrying the same sessionId (exercises the real _isNewSessionId gate, not a mock).

No blocking or nit findings. Clean, well-scoped diff; provenance and fail-open properties for a security-relevant attestation path are all traceable to a trusted local subprocess boundary.

scanners_run: gitleaks/trufflehog/semgrep/osv-scanner not available in this sandbox (no scanner binaries wired for this invocation) -- judgment-only review performed instead, diff obtained via bobbie-github-security read (GitHub API) against #421, base 8302c71 verified resolvable.

{"reviewer": "bobbie", "review_status": "clean", "head_sha": "73b32863a85479fafe7dc2dda067a960ca52dc96", "pr_number": 421}

[clagentic-reviewer]

PEACHES — clean (0 blocking, 1 design observation)

The fix closes the race condition documented by the user, and the re-verified contract items hold at new head SHA 6764e37:

1. Production signature unchanged, fire-and-forget preserved:

• lib/lore-attestation.js line 46: attestHumanSession(sessionId, onSettled) adds optional second param.
• lib/sdk-message-processor.js line 255: Production call site passes exactly ONE argument: loreAttestation.attestHumanSession(session.cliSessionId) — onSettled remains undefined, fire-and-forget contract intact.
• Production code cannot reach the test hook (no production caller passes a function).

2. Race condition closed, genuinely awaited:

• Test rewrite: line 32–42, the first test registers the onSettled callback and receives a done parameter from node:test framework (line 32). The callback invokes done() at line 39 — the test framework will not mark the test complete until done() is called, forcing it to block on execFile resolution.
• Invalid-input early-return (lines 47–49): onSettled fires synchronously with null before any spawn.
• Async execFile callback (lines 52–64): onSettled fires at line 63 once the child settles.
• Outer catch (line 69): onSettled fires if execFile itself throws.
• No process.env.PATH mutation: eliminated the sync-restore vs async-spawn race.

3. No leaked handles:

• First test: done() blocks test completion until execFile settles.
• Second test (lines 44–54): invalid-input branch fires onSettled synchronously (line 113 asserts settledCount === 4).
• Eliminated original defect: test no longer mutates global PATH and races cleanup.

4. Prior contract items confirmed at new SHA:

• Human-presence boundary (project-user-message.js line 384): humanOriginated = true only in live-WS handlers, never in headless paths (project-loop.js, scheduler.js).
• Correct id: keyed on session.cliSessionId (Codex rollout/thread id).
• Fail-open: all errors swallowed, logged appropriately.
• Idempotence: session state not modified by attestation.
• CLI-only: execFile invokes lore CLI only.

Design observation (peaches.nit.observation):
The test-only onSettled hook adds a production signature. Alternatives (injecting execFile, exporting an internal) would be more conventional but add infrastructure overhead. This seam is defensible: the hook is optional, production code has one call site that does not pass it, the type check ensures it is inert, and it avoids the test hazard (global mutation + async spawn race + leaked handles). Defensible minimal fix.

{"reviewer": "peaches", "review_status": "clean", "head_sha": "6764e377f5614e2fff4996519f92c891d06c830b", "pr_number": 421}

[clagentic-security]

BOBBIE re-audit of PR #421 at head 6764e37 (base 8302c71, self-fetched from the live PR via bobbie-github-security read, not hand-counted).

SCANNER SWEEP (base..head, 8302c71..6764e37):

• gitleaks detect: run/clean. 2 commits scanned, no leaks found.
• trufflehog git (since-commit=8302c71, branch=6764e37): run/clean. 0 verified_secrets, 0 unverified_secrets across 12 chunks/21716 bytes.
• semgrep --config=auto (5 changed/added files): run, 5 raw findings, all DROPPED at the Pre-Report Gate: lore-attestation.js line 60 console.error is unchanged since 73b3286, interpolated value is session.cliSessionId not attacker input; project-user-message.js lines 417/659 path.join hits are pre-existing lines this diff never touches (diff 8302c71..6764e37 for that file only touches lines 329-333 and 367-388).
• osv-scanner against package-lock.json: run, repo-wide findings present (e.g. GHSA-frvp-7c67-39w9) but N/A to this PR -- diff --stat 8302c71..6764e37 for package.json/package-lock.json is empty, no manifest changed.

MANUAL VERIFICATION (re-confirmed at 6764e37):

1. Production call site sdk-message-processor.js:255, attestHumanSession(session.cliSessionId), exactly one argument, confirmed the ONLY call site (lore-attestation.js history is two commits total; sdk-message-processor.js is the only importer added). onSettled never reachable from production; no attacker-influenceable second argument possible.
2. onSettled exception path, all three sites in lore-attestation.js: line 48 (invalid-input, synchronous) a throw propagates to the caller unguarded; line 63 (execFile async callback) is OUTSIDE the lexical try/catch at lines 51-70, a throwing onSettled there would be an uncaught event-loop exception capable of crashing the daemon absent a global handler -- a real structural hazard in the contract as written; line 69 (outer catch) a throw from onSettled still re-propagates synchronously. Foreclosed today only by the single-call-site fact in item 1: latent, not live. No rule fits an unreachable hazard; not reported as a finding.
3. execFile uses argument-array form, no shell interpolation. sessionId is session.cliSessionId from the Codex adapter own thread/start notification, a trusted local subprocess. humanOriginated is written only in project-user-message.js message and send_scheduled_now WS handlers (lines 384, 335), both gated on getSessionForWs(ws) resolving an already-authenticated bound session; project-loop.js/project-external-trigger.js/scheduler.js never reach it, unchanged since 73b3286. The isNewSessionId gate fires attestation at most once per session lifetime. No unhandled-rejection path -- attestHumanSession is fully callback-based, never returns a Promise.
4. Tome 845 check on test/lore-attestation-lr-f7c100.test.js: primary test uses node test (t, done) async-completion form, does not resolve until done() fires, and done() fires only from inside onSettled, itself only invoked by the real execFile completion callback (or synchronously on invalid input). Genuine await-of-settlement, not register-and-continue; tome 845 defect class not reproduced.

FINDING: none blocking. No RULEBOOK.md rule triggered. The onSettled async-exception-context gap (item 2, line 63) is real code-shape debt but has no citable reachable production path today -- fails the Pre-Report Gate severity test, not reported as a finding.

{"reviewer": "bobbie", "review_status": "clean", "head_sha": "6764e377f5614e2fff4996519f92c891d06c830b", "pr_number": 421}

[clagentic-merger]

Merged via clagentic-loadout v0.2.0

Field	Value
Gated HEAD SHA	6764e377f5614e2fff4996519f92c891d06c830b
Merged SHA	6764e377f5614e2fff4996519f92c891d06c830b
Reviews	clagentic-reviewer[bot], clagentic-security[bot]
CI status	no-runner-by-design (0 commit-status entries at HEAD)
task_id	lr-f7c100