OpenClaw Lane A live capture: client-header attribution, settlement match keys, Responses-API decoder (LLP 0175/0176)

[bgmcmullen]

Summary

A day of live investigation found OpenClaw's Lane A (gateway live capture) completely non-functional, with three stacked causes, each fixed and re-verified against live traffic:

1. Attribution (LLP 0175 root cause):attach.js wrote only the x-hypaware-upstream routing marker, never the x-hypaware-client: openclaw header the openclaw exchange projector's match() keys on. Anthropic-shaped exchanges fell through to the Claude projector (misattributed, never settled, and duplicated against the sweep, replaying full conversation history per capture); OpenAI-shaped exchanges matched no projector and vanished silently. Attach now writes both headers; ownership still keys on the marker alone so pre-fix entries detach cleanly and a re-attach upgrades them in place.
2. Settlement residual (LLP 0175): OpenClaw prepends [Mon 2026-08-03 15:33 PDT] to user messages on the wire but stores bare text in its session file, so user turns content-missed while assistant turns settled. match_key.js now normalizes the wire-only stamp out of text identity, symmetrically on both builders.
3. Responses-API blindness (LLP 0176): the projector's OpenAI branch spoke only Chat Completions; OpenClaw speaks /v1/responses. A third parse branch decodes Responses exchanges (input items, tool calls/results, reasoning-as-thinking, streamed reconstruction from the terminal response.completed payload, usage netted through the existing gross-minus-cached path). Decoded turns emit the shared block vocabulary so they settle under the same match keys the session file yields, honoring the fix-ordering constraint (settlement first, decoder second). The dispatcher's no_projector_match warn now names path/method/status/is_sse so an undecoded dialect can never again masquerade as an unattached client.

Ships LLP 0175 + 0176 (Draft, round-1 reviews included) recording the full evidence chain.

Verification

• npm test: 3302/3303 (the 1 failure is pre-existing on master: usage-policy-fold, confirmed identical with these changes stashed)
• hyp smoke client_attach_idempotent: green
• Live end-to-end on a real OpenClaw install: Anthropic turn and OpenAI (Responses) turn each captured within seconds, client_name: openclaw, correct provider/model, settled onto the native session file identity, and the subsequent sweep pass added zero duplicate rows.

Out of scope (documented in the LLPs)

• Subscription/OAuth traffic (hardcoded ChatGPT endpoint, unreachable by config; sweep is the documented ceiling)
• Error-status exchange recording (LLP 0176 fix 2, unverified)
• Sweep-side per-session provider stamping on mixed-provider sessions
• Cache remediation of rows written pre-fix

🤖 Generated with Claude Code

[philcunliffe]

Review: findings (no blockers)

The three claimed areas are real and correctly aimed. isOwnedProviderEntry keys on the marker alone, so pre-fix entries still detach and re-attach upgrades in place, and the new test proves it. The match-key strip is applied symmetrically through reduceBlock, so it cannot create one-sided drift, and it adds no session-side ambiguity because the session file never carries the prefix. Settlement's existing ambiguity guard (buildOpenclawSessionIndex deletes a key two messages share) still protects the collision case. Unmatched settlements are accounted for rather than dropped: plugin.openclaw.settlement logs unmatched and the rows keep fallback identity. x-hypaware-* headers are stripped in forwardHeaders() before forwarding, so the new client header never reaches a provider. Conventions are clean: no em dashes, no semicolons, no inline import() types, no @typedef, no dangling .d.ts specifiers.

Verified beyond the test suite: a function_call_output item and OpenClaw's role: "toolResult" record produce the same match key, in both the string-output and array-output forms.

Pushed (mechanical only)

e44bb7a - retarget the timestamp-prefix @refs. Three annotations pointed at LLP 0175#root-cause, which documents only the missing x-hypaware-client header and says nothing about the wire timestamp prefix (that is Fix direction item 2). Added {#fix-direction} to that heading in LLP 0175 (Draft, so editable) and retargeted match_key.js:100, test/plugins/openclaw-match-key.test.js:53, test/plugins/openclaw-settlement.test.js:360. The attach-side ref at attach.js:43 correctly stays on #root-cause. No behavior change.

Handed back

1. major - openclaw/src/match_key.js:95: the timestamp regex only matches US-style zone abbreviations, so the LLP 0175 residual stays open for most non-US users.

[A-Z]{1,6} matches PDT/EDT/UTC but not the offset-style short names JS emits for most of the world:

America/Los_Angeles PDT -> stripped
Europe/Berlin GMT+2 -> NOT stripped
Asia/Tokyo GMT+9 -> NOT stripped
Asia/Kolkata GMT+5:30 -> NOT stripped

Confirmed: wireMatchKey('user', '[Mon 2026-08-03 15:33 GMT+8] hi') !== wireMatchKey('user', 'hi'). If OpenClaw builds the stamp with timeZoneName: 'short' (which the observed PDT is consistent with), every user turn from a GMT+/-N zone content-misses exactly as LLP 0175 describes, and the fix silently only works where it was tested. Suggested fix: widen the zone group to accept an offset tail, e.g. [A-Z]{1,5}(?:[+-]\d{1,2}(?::\d{2})?)?, and add the GMT+2 / GMT+5:30 cases to the near-miss test table. If you can confirm from the OpenClaw source that the stamp is always an alpha abbreviation, say so in the WIRE_TIMESTAMP_PREFIX doc comment and this drops to a non-issue, but nothing in the comment or tests establishes that today.

2. minor - projector.js:1114-1118: a Responses stream cut before any response.output_item.done emits an empty assistant row and discards the text deltas it did capture.

Reproduced: with response.created then response.output_text.delta: "partial text" and nothing else, sawResponsesEvent is true, doneItems is empty, and the projector emits:

{ "role": "assistant", "content": [], "stop_reason": "error",
"attributes": { "openclaw": { "match_key": "5d008246..." } } }

The docstring says the stream "degrades to the response.output_item.done items that did finish", but with zero such items there is nothing to degrade to and a row is written anyway. Two consequences: the captured response.output_text.delta payloads are thrown away (the Chat Completions sibling stitches its deltas and keeps the partial text), and the content-free row still carries a match key and a message_index, so it is eligible for the ordinal fallback and can acquire a native message_id it has no content for. Minimum fix: if (!terminal && doneItems.length === 0) return undefined. Not pushed, because your LLP text records that "per-delta stitching of a half-finished item is deliberately not attempted", so choosing between "emit nothing" and "stitch the deltas" is your call.

3. minor - projector.js:325-336: openclawSessionId's fallback chain has no Responses branch, so an instruction-less Responses request gets a per-exchange session id.

The chain is systemText -> reqBody.messages[0].content -> exchangeId. A Responses request carries input, never messages, so a request with no instructions and no leading system/developer item falls straight to hashShort(exchangeId):

sid for exchange ex-A = 9607356ea130e4fc
sid for exchange ex-B = e54b5640f0127833 # same conversation, different session

That fragments Lane A session grouping for exactly the traffic this PR just made recordable. In practice OpenClaw always sends instructions, which is why the tests do not hit it, but the fallback exists precisely for when it does not. Suggested fix: add an input-array branch alongside the messages branch.

4. minor - LLP 0176 fix 2 is now more consequential than when it was written. With the client header landing, an error-status exchange in a matched shape no longer falls out at the unmatched-drop layer: it projects the request-side turns and no assistant row, with nothing marking it as failed. Confirmed a 400 Responses exchange writes the user turn and stops. That is the state fix 2 already describes as open, so it is not a regression from this PR, but the PR changes it from "records nothing" to "records a prompt with no reply and no error signal", and a reader of ai_gateway_messages cannot distinguish that from a turn the model never answered. Worth a sentence in LLP 0176 fix 2 noting the changed shape of the gap.

5. minor - the header-absent fallback is still wrong-but-confident, and only the issue doc says so. With no x-hypaware-client, an Anthropic-shaped exchange from any client is claimed by the Claude projector at priority 100 and stamped client_name: claude. LLP 0175 names this as a corollary and parks it in Open questions, which is fair for this PR's scope. Flagged only so it does not get lost: it is the same failure that produced the fbe6c615e2b31ab1 mess, just for the next unrecognized client rather than OpenClaw.

6. minor - test coverage gaps for the failure modes. The Responses tests are strong on the happy path and cover the cut-stream, incomplete-response, near-miss-bracket and mid-text-stamp cases well. Missing: (a) a function_call_output to session-file toolResult match-key test (verified passing by hand, but it is the reconciliation most likely to break silently under a shape change); (b) an unknown or future input item type asserting it projects nothing rather than a malformed turn; (c) a truncated response_body on the /v1/responses path asserting the request turns survive and the assistant is simply absent (also verified working, untested). None blocking.

7. nit - issue docs are still Status: Draft while code @refs them as [implements]. LLP 0175 fixes 1 and 2 and LLP 0176 fixes 1 and 3 are all marked DONE in-document. Other Issue-type docs in the corpus are Active (0095) and Accepted (0110). Consider promoting these to Active, since 0176 fix 2 remains genuinely open.

8. nit - message_projector.js:206 logs the full path, which includes the query string (proxy.js:147 sets path: requestUrl, not parsedUrl.pathname). Harmless for Anthropic and OpenAI, but a TOML-configured upstream that authenticates via a query parameter would put that credential into a warn line. The value is already persisted in the exchange row, so this is not a new exposure class, just a new surface. parsedUrl.pathname carries the same diagnostic value.

Verification

• npm test: 3302 passed, 1 skipped, 0 failed
• npm run typecheck: clean
• Pushed: e44bb7a on openclaw/lane-a-live-capture-fixes

Note on LLP numbering

This PR's llp/0175-* collides in number with a doc on a neutral-owned PR (#585). That is being resolved on the other branch by renumbering it to 0178. This PR keeps 0175 and 0176 unchanged, no action needed here. Flagging it because the duplicate-numbers check validates each PR against master in isolation, so it passes on both and the duplicate would only surface on master after the second merge.

[philcunliffe]

Review round 2: findings

The only delta since the round 1 record (535f8cc) is e44bb7a, which neutral itself pushed: three @ref anchor retargets from LLP 0175#root-cause to #fix-direction, plus the {#fix-direction} anchor definition on that heading. Four single-line changes, no behavior change, npm test and npm run typecheck clean.

Every finding in the round 1 record still stands unaddressed at this head. Verdict is unchanged: changes requested, on finding 1.

Blocking ask - openclaw/src/match_key.js:97.WIRE_TIMESTAMP_PREFIX ends its zone group with [A-Z]{1,6}, which matches alpha abbreviations (PDT, EDT, UTC) but not the GMT+N short names JS emits for most non-US zones. The result is that the settlement residual this PR sets out to fix stays open for those users, while the tests (which only exercise PDT) report success. Either widen the group to accept an offset tail and add GMT+2 / GMT+5:30 to the near-miss table, or, if OpenClaw's stamp is provably always an alpha abbreviation, record that in the WIRE_TIMESTAMP_PREFIX doc comment so the narrower pattern is justified rather than incidental.

Findings 2 through 8 are non-blocking and yours to take or leave. Findings 2 and 3 in particular are cheap guards worth considering before this lands.

Reply on this thread or push to the branch, and neutral will re-engage on its next tick.

[philcunliffe]

Requesting changes on one finding; the full review records are in the thread (rounds 1 and 2).

openclaw/src/match_key.js:97 - WIRE_TIMESTAMP_PREFIX's zone group [A-Z]{1,6} matches PDT/EDT/UTC but not the GMT+N short names JS emits for most non-US timezones. So the settlement content-miss this PR fixes stays open for those users, while the tests (which only cover PDT) report success.

Either widen the group to accept an offset tail, e.g. [A-Z]{1,5}(?:[+-]\d{1,2}(?::\d{2})?)?, and add GMT+2 / GMT+5:30 to the near-miss test table; or, if OpenClaw's stamp is provably always an alpha abbreviation, say so in the WIRE_TIMESTAMP_PREFIX doc comment so the narrow pattern is deliberate rather than incidental.

Everything else in the review is non-blocking. The three areas this PR targets all check out otherwise, and e44bb7a (an @ref anchor retarget) was pushed on your branch under neutral:adopt.

[bgmcmullen]

Pushed 106609c addressing the blocking finding plus findings 2, 3, 4, and 8.

• Finding 1 (blocking): took the widen route. Nothing in the OpenClaw source or LLP 0175 evidence proves the stamp is always an alpha abbreviation (the observed PDT is consistent with timeZoneName: 'short', which emits GMT+N for most non-US zones), so the zone group now accepts an offset tail: [A-Z]{1,6}(?:[+-]\d{1,2}(?::\d{2})?)?. Kept {1,6} rather than narrowing to {1,5} to avoid regressing any stamp the old pattern already accepted. Added GMT+2 / GMT+5:30 / GMT-7 / UTC+10 as positive cases and GMT+123 / GMT+5:3 / GMT+ to the near-miss table, and the doc comment now records why the offset form is in scope.
• Finding 2: took the emit-nothing option (consistent with the documented no-delta-stitching stance): a cut stream with zero finished items returns no assistant row, with a test asserting the last projected message stays the user turn.
• Finding 3: openclawSessionId falls back through the input array when messages is absent, with a test proving two exchanges sharing an instruction-less Responses conversation get one session id.
• Finding 4: added the changed-shape sentence to LLP 0176 fix 2.
• Finding 8: the aigw.message_projection_skipped warn now logs the pathname only.

Findings 5, 6 (beyond the tests the fixes above added), and 7 are left as-is for follow-up.

npm run typecheck clean; openclaw suites 186/186. npm test shows one failure in test/core/usage-policy-fold.test.js ("fold_tightened only when folding changed the verdict") that is pre-existing: it fails identically at e44bb7a with a clean tree on this machine, so it looks environment-dependent (NFC/NFD fold behavior), not related to this branch.

[philcunliffe]

Review round 3: clean

106609c resolves the blocking finding and findings 2, 3, 4 and 8. Each was verified empirically rather than by reading, and every new test was reverted to confirm it actually holds its fix in place. No blockers remain.

Finding 1 (blocking): resolved

Built the stamp the way OpenClaw's observed shape implies (Intl.DateTimeFormat, weekday:'short', ISO date parts, hour12:false, timeZoneName:'short') across a spread of zones and compared wireMatchKey(role, stamped) against wireMatchKey(role, bare):

zone	short name	strip
America/Los_Angeles	PDT	PASS
America/New_York	EDT	PASS
Europe/Berlin	GMT+2	PASS
Europe/London	GMT+1	PASS
Asia/Tokyo	GMT+9	PASS
Asia/Shanghai	GMT+8	PASS
Asia/Kolkata	GMT+5:30	PASS
Asia/Kathmandu	GMT+5:45	PASS
Asia/Yangon	GMT+6:30	PASS
Australia/Adelaide	GMT+9:30	PASS
Pacific/Chatham	GMT+12:45	PASS
Pacific/Marquesas	GMT-9:30	PASS
America/St_Johns	GMT-2:30	PASS
Pacific/Kiritimati	GMT+14	PASS
Africa/Nairobi	GMT+3	PASS
UTC	UTC	PASS

16 of 16. The two-digit-hour-plus-45-minute case (GMT+12:45) and the negative half-hour case (GMT-2:30) both clear the \d{1,2}(?::\d{2})? tail, so the widened group is not merely wide enough for the common cases.

On the locale question: the observed Mon plus 2026-08-03 combination is en-CA shaped (en-US renders 08/03/2026), and en-CA emits PDT for LA and GMT+5:30 for Kolkata with ASCII signs. The fix targets exactly the formatter the evidence points at.

No over-strip. Diffed the old pattern against the new across 20 strings. The only behavior changes are the six real GMT-offset stamps; every near-miss still returns keep, including a 3-digit offset, 1-digit minutes, an empty offset, a 7-char zone, a lowercase weekday, a missing trailing space, and a non-anchored inline occurrence. The change is strictly additive, and you extended the near-miss table correctly.

Finding 2: resolved

if (!sawResponsesEvent || doneItems.length === 0) return undefined (projector.js:1124). The guard is correctly scoped rather than blanket:

terminal response.completed with output: [] -> user | assistant:[] (still records)
cut, one output_item.done -> user | assistant:[text] (degrades)
cut, zero done items, only output_text.delta -> user (no assistant row)

It removes the harmful half (a content-free row acquiring a native message_id through the ordinal fallback). It does not match Chat Completions, which stitches deltas and keeps partial text, but that asymmetry is deliberate and the docstring now states it. LLP 0176 says nothing about stitching or cut streams, so there is no doc/code mismatch.

Finding 3: resolved (array form)

input=[{role:'user',content:'first turn'}] ex-A -> 1b647f991595be7e
input=[first, assistant reply, second turn] ex-B -> 1b647f991595be7e stable as the conversation grows
input=[{role:'user',content:'different convo'}] ex-C -> 0dd257d7def2e4ef distinct

Finding 4: resolved, and the doc is accurate

Verified rather than trusted. A 400-status Responses exchange in a matched shape projects one user turn, no assistant row, and no error signal anywhere, exactly as the added sentence says.

Finding 8: resolved

(stringValue(input.path) ?? '').split('?')[0] is equivalent to parsedUrl.pathname for this purpose.

Revert tests

fix reverted	test	result
zone group narrowed back to [A-Z]{1,6}	the timestamp strip accepts GMT-offset short zone names	fails (not ok 7)
|| doneItems.length === 0 removed	a stream cut with zero finished items emits no assistant row	fails (not ok 9)
input-array branch removed	openclawSessionId keys on the first input item ...	fails (not ok 9)

All three load-bearing. None passes both ways.

Regressions: none

attach.js, proxy.js and settle.js are untouched. Re-verified anyway: the x-hypaware-* strip at proxy.js:385; the settlement ambiguity guard at settle.js:391-392; unmatched settlements still counted at settle.js:220; and function_call_output still reconciling with role: "toolResult" (both hash to 21f5138c5b823b19, in both the string-output and array-output wire forms).

Residuals (minor, not asks, neither introduced here)

A. The empty-assistant-row fix is Responses-only; both siblings still emit it. Reproduced on Chat Completions (cut stream, role-only chunk) and Anthropic (cut stream, message_start only): both write assistant [] with stop=error and match key 5d008246, byte-identical to the Responses row round 1 quoted. All three paths converge on one canonical empty-assistant key, and two still write it with a live message_index, so the ordinal-fallback exposure you closed for Responses remains open for the other two. Predates this PR, so not a regression, but the fix is now asymmetric. Tracked separately rather than expanding this PR's scope.

B. The input branch covers the array form only; a string input still fragments.openaiResponsesMessages supports input: 'hi' (projector.js:846), and your own new cut-stream fixture uses that form, but openclawSessionId does not: two exchanges with { input: 'hi there' } yield 9607356ea130e4fc and e54b5640f0127833. Left as a hand-back rather than a push, because grouping a conversation that opens as a string and continues as an array requires the string form to hash the same way the object branch's JSON.stringify(messages[0].content) does, and picking that is your call.

Conventions

Clean across all seven touched files. No em dashes, no semicolons, no inline import() types, no @typedef, no dangling .d.ts specifiers. The delta adds no @ref annotations; LLP 0175#fix-direction and LLP 0176#fix-direction both still resolve.

Verification

• npm test: 3305 passed, 1 skipped, 0 failed
• npm run typecheck: clean
• Pushed: nothing. Everything landed correct; the two residuals are design calls, not mechanical fixes.

You took the harder route on finding 1, widening the pattern rather than asserting the narrow form was safe, and it was the right one. All four findings are genuinely closed, and the tests hold them closed.

[philcunliffe]

Approving. All four findings from the earlier rounds are resolved, and I verified each empirically rather than by reading the diff: 16 of 16 real timezone stamps now strip (including the 45-minute and negative half-hour offsets), and all three new tests were confirmed to fail when their fix is reverted, so they are load-bearing.

Widening the zone pattern rather than asserting the narrow form was safe was the right call.

Two residuals are noted in the review record as observations, not asks: the empty-assistant-row guard is Responses-only while Chat Completions and Anthropic still emit the same row shape (pre-existing, tracked separately), and openclawSessionId's new branch covers the array input form but not the string form.

Merging is the maintainer's call; neutral holds here.

[philcunliffe]

Merge note: one line to change if this lands after #592

Not a review finding and nothing to fix here. Flagging a cross-PR interaction discovered while reviewing #592 ("a cut stream with no content emits no assistant row").

#592 adds a shared floor at the projector's row-assembly point that drops an assistant row when a stream was cut and captured no content. Its first implementation keyed cut-ness on stop_reason === 'error'; review found that conflates the synthetic marker with a value real upstreams send (OpenRouter-class gateways emit finish_reason: "error"), silently dropping genuine terminal error rows. It now carries cut-ness out of band in a WeakSet, populated only by markCutStream(message).

The interaction: this PR's responsesAssistantFromStream writes partial.stop_reason = 'error' as a bare literal. Under the original string-comparison floor the Responses path would have inherited the drop automatically; under identity-based cut-ness it does not.

Concretely: on the merged tree, a cut Responses stream whose one finished item is of a type openaiResponsesAssistant does not map (e.g. image_generation_call) emits a content-free row with a live message_index, which is the ordinal-fallback identity hazard #591 is about. Your own doneItems.length === 0 guard already covers the main case, so this is a narrow residual.

The fix, at merge time: replace partial.stop_reason = 'error' with markCutStream(partial). That is why markCutStream exists as a function rather than two statements, and its docstring says so.

Verified: the two branches merge cleanly (ort, no conflicts) and 194/194 openclaw tests pass on the merged tree. A terminal response.completed whose output really is [] is preserved either way, because openaiResponsesAssistant gives it no stop_reason at all.

Merge order does not matter; whichever lands second wants this one-line edit. This PR's own approval stands unchanged.