Skip to content

test(claude): exclude record timestamps from privacy scans - #779

Merged
stamp-build[bot] merged 1 commit into
mainfrom
agent/otter/claude-usage-privacy-clock
Nov 13, 2026
Merged

stamp-build[bot] merged 1 commit into
mainfrom
agent/otter/claude-usage-privacy-clock

Conversation

@stamp-build

@stamp-build stamp-build Bot commented Nov 13, 2026

Copy link
Copy Markdown
Contributor

Otter from open-agent-runtime opened this pull request through Stamp
View in Stamp →


The Claude usage privacy tests searched the entire serialized record for numeric synthetic account values. A legitimate receivedAt such as 1794612345600 contains 123456, causing a privacy failure even when no account data was recorded. This matches the value and time window of the Windows failure in PR #768; the original test did not retain its record array.

Search record bodies, including native frame contents and observer records, where the private responses would be exposed. Both affected scenarios now pin only Date to that collision timestamp; timer behavior, private numeric fixture values and the existing readback/usage assertions remain intact. Runtime code is unchanged.

Validation:

  • Fixed-clock reproduction: the previous assertions failed in four cases while the baseline record bodies contained none of the private values.
  • Both focused files pass all 10 cases with the corrected assertions.
  • Negative control: injecting an untracked native reply containing the synthetic private values makes those four cases fail at the corrected privacy assertions. The injected reply was removed.
  • Full CI=1 pnpm run check: passed, including 4,131 tests and 18 mock behavior cases.

This is a separate main-based test fix. PR #768 remains an exact contributor mirror and must not be merged.

@stamp-build
stamp-build Bot merged commit 76f5ef6 into main Nov 13, 2026
53 of 54 checks passed
@stamp-build
stamp-build Bot deleted the agent/otter/claude-usage-privacy-clock branch November 13, 2026 23:58
stamp-build Bot added a commit that referenced this pull request Nov 14, 2026
<!-- stamp:origin:v1 {"Name":"Cindy","ServerID":"6aabf32c-20bc-4cba-b55a-2aa72b60999b","System":false} -->

<!-- stamp:review:v1 -->
<sup><img src="https://api.raft.build/api/avatars/pixel/bXVn.svg" width="16" height="16" align="absmiddle" alt=""> <b>Cindy</b> from open-agent-runtime opened this pull request through Stamp</sup><br><sup><a href="https://stamp.build/github/botiverse/oar/pull/781?server=open-agent-runtime"><picture><source media="(prefers-color-scheme: dark)" srcset="https://stamp.build/assets/brand/stamp-glyph-dark.d907ffcadb44.svg"><img src="https://stamp.build/assets/brand/stamp-glyph-light.58a2c10ed108.svg" width="13" height="12" align="absmiddle" alt=""></picture> View in Stamp →</a></sup>

---
<!-- /stamp:review:v1 -->

OpenCode 2.x sessions can steer: a message sent while a turn runs joins that turn, through OpenCode's own steering extension.

## OpenCode v2: steering through `_session/steering` (#780)
- OpenCode registers `_session/steering` (its interim extension until ACP has native mid-turn steering) from **2.2.7**, and advertises it in `initialize`'s top-level `_meta: { steering: { supported: true } }`. OAR gates on that advertisement, not on a version: a v2 session has `steer` only when it is advertised. 2.2.6 and older, and the shared 2.2.3 / 2.2.5 placement, keep no `steer` member, as before.
- `steer` sends `_session/steering { sessionId, prompt }` while an OAR turn runs. `injected` is `accepted` and the turn still ends with the original prompt's answer; `promptRequired` (reason `noRunningTurn`) is `rejected` / `no_active_turn`; each answer is recorded as one `_session/steering` frame (`native` verbatim, `responseTo` the steer request); a JSON-RPC error is `runtime_refused` with a `_session/steering/error` frame instead; an unknown outcome is `rejected` / `error`. No request is sent when OAR has no turn, an abort is pending, or the turn ended before dispatch. The extension has no input-id field, so `inputId` lives on OAR's steer request record.
- What hosts see: on 2.2.7 and later `session.steer` exists; `deliver({ when: "now" })` and `steerOrQueue` steer into a running OAR turn; `when: "interrupt"` now steers instead of withdrawing, aborting and merging.
- Checked natively on 2.3.0 (Linux x64, local provider): steers during a reply and during a running tool reach the same turn's next model request and end with it; an image with text reaches the model. A steer is plain text: slash commands are not executed (send them with `prompt()`). Abort does not withdraw an accepted steer: the turn ends `aborted`, and OpenCode keeps the steered text for the next prompt's model request (no `input_dropped`), as on 1.18.35. Not run natively: 2.2.7, and the race where the session goes idle between OpenCode's check and its submission.

## `deliver`: a refused steer during a still-running status queues (#780)
- In `shared/deliver.ts`, a steer refused `no_active_turn` while the status still shows the same running turn now queues the input instead of retrying until `busy`. It applies on the steer path (`when: "now"`, and `when: "interrupt"` where `steer` exists); `steerOrQueue` is unchanged. This covers OpenCode 2.3's parent reply after a background subagent (status `running` with no OAR turn; the queued input is sent at once; the records now show a steer request refused `no_active_turn`, with no native request, before the queue entry) and any runtime whose abort is pending. Other refusals are unchanged.

Tests only: Claude privacy tests no longer scan record timestamps for synthetic account values (#779).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Cindy <open-agent-runtime+cindy@agents.stamp.build>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants