Both findings from the exact-build security review (PAP-16983) against
`b73524ec2ac5`.
Sensitive information disclosure: every projected view carried raw
`provider_event` records and unredacted tool results, so one ordinary turn
handed an admitted browser provider protocol traffic, the echoed prompt,
provider thread/turn/item identifiers, model and token metadata, and complete
tool payloads. Redaction now happens where evidence is recorded, not where it
is rendered — `redactPhase7EvidenceData` is the only way an entry enters a live
session, so a raw payload never reaches the snapshot, the store, a frame, or a
log. `toPhase7PublicThreadView` then publishes an allowlisted DTO on every
response path, aliases provider-authored identifiers consistently, and scrubs
withheld provider identity. A streamed failure answers with a code and fixed
operator copy instead of the underlying message.
Cross-session BOLA: the only capability was minted once per gateway process, so
possession of a session id authorized reads and mutations of it. Each surface
now mints a per-browser capability, stores only its SHA-256 with the session,
and compares it in constant time on every session-scoped route. A valid id
without its capability is answered 404, exactly like an id that never existed.
`New chat`, a scenario POST, and reset rotate the capability after revoking the
caller's prior bindings.
Also normalises the stream frame cap to encoded UTF-8 bytes rather than UTF-16
code units, which the review flagged as low-severity hardening.
Each new test was observed failing against the reinstated rejected behaviour
(19 failed, 18 pre-existing passed) before passing against the fix.
Refs PAP-16991.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The clean-room chat revealed a finished reply instead of writing one: the
live session accumulated agent deltas in its turn waiter, the package
session server awaited the whole turn and answered with one JSON body, and
the browser waited on `response.json()`. Nothing between the provider and
the page could show work in progress, so the board saw the answer appear
all at once.
A turn now streams:
- `Phase7LiveSession` publishes bounded, ordered live turn events and
mirrors the waiter's assembled text into the transcript entry the reply
will finally occupy, so one rendered card grows and the settled text is
still assembled in exactly one place.
- `src/phase7/turn-stream.ts` defines the NDJSON frame codec and reader.
The decoder refuses a replayed, reordered, oversized, late, or truncated
frame rather than applying a stale view.
- `POST /api/phase7/ui/message` flushes headers, then writes one frame per
event-loop tick of provider activity. Admission checks still answer with
a JSON body and their own status code, because they are decided before
the first frame. Client disconnect interrupts the provider turn.
- The browser client consumes frames and renders each projection in place;
the settled payload is applied last and remains the authority. Stop,
reset, and `New chat` abandon the stream, and frames from an abandoned
turn generation are dropped.
Measured against real Codex through real runnerd: headers at 265 ms, 62
growing assistant states from the first character to a 301-character reply
at 3.1 s, the last interim state identical to the settled one, and a single
assistant card in the settled thread.
The scenario explorer and every fixture, preset, and replay route are
unchanged and stay deterministic.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Phase 7 issue-thread live region re-armed "A request is waiting for
your answer." on every snapshot while a request was pending. On the live
path a submit re-renders with the same request still pending (state
`submitting`), so the pending copy overwrote "Your answer was recorded."
and then stayed put once the request settled — clean-room QA (PAP-16974)
heard the stale guidance during later turns.
The pending copy is now announced once per request, on arrival, and the
settle path replaces it (and only it) with the request's resolved state
label, so a request that goes away server-side corrects itself too.
Covers pending -> answered -> later turn, plus a server-side withdrawal,
in the issue-thread browser suite: 60/60 pass, `check:phase7:ui` still
reproduces all 24 screenshots byte-for-byte.
Adds a second primary path beside the preset scenario explorer. `#/chat`
opens a blank thread on a freshly minted mock tenant — one company, one
agent, one blank issue — and drives real Codex through real runnerd. The
scenario explorer and its deterministic deep links are unchanged.
The clean room is live-only by construction. The route pins `mode=live`
and drops `shot`/`at`, the package server has no scripted path for it and
refuses any non-live projection, and a failure to start runnerd or Codex
is reported with a retry rather than replaced by a fixture.
`createPhase7CleanRoomSessionInput` seeds the minimum a runner session
needs and fails closed if anything else is present, so "starts blank" is
enforced at the seam rather than assumed. The exposure profile is fixed
and inspectable while the calls stay conversation-driven; three grants
(`governance:approvals:decide`, `workspace:control`,
`test:generic_api_request`) stay withheld so a typed denial is reachable
in a chat nobody scripted.
`Reset` and `New chat` retire the previous session's authority, drop its
workspace, and mint new mock identities; the old session id answers 404
afterwards. The projection now publishes the real-API block as a
`network-guard-<sessionId>` control-plane record, so "no request reached
a real Paperclip API" is inspectable in the drawer on both surfaces.
Also fixes two things the clean room surfaced: the unanchored `sk-`
credential heuristic matched mock ids of the form `task-cleanroom-<token>`,
and a hash change left one committed frame reporting `settled` for the
surface just navigated away from.
The 24-image screenshot matrix is re-recorded: the surface rail carrying
the clean-room entry is a real, always-visible element, and it reproduces
byte-for-byte against Chromium 151.0.7922.34.
Verified: test:phase7 159/159; test:browser:issue-thread 58/58 with axe
clean; check:phase7:ui 24/24 byte-identical; docs:validate 93 files, 34
OKF concepts; smoke:phase7:cleanroom all 15 assertions true against real
Codex 0.132.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Five protocol corrections from the CTO review of the Phase 4b work.
Canonical runtime request outcome. The real driver emitted `resolution`
while the scripted driver and browser read `action`, so a real resolved
card reported an unknown outcome. `harnessRuntimeRequestOutcome` is now
the one payload every driver emits for a terminal `runtime_request.*`
fact, carrying `requestId`, `requestKind`, `turnId`, and `itemId` in the
payload as well as the event binding.
Decoded request identities. Path segments are split before they are
decoded, so a percent-encoded reserved character stays inside the segment
the browser meant it for; malformed encoding fails with 400.
Resolution shapes validated by request kind.
`parseHarnessRuntimeRequestResolution` requires `answers` for a
`user_input` submit and `content` for an elicitation submit, and rejects
a mismatched body instead of accepting it as an empty response. Both
drivers and the browser transport run it, and the request card now sends
elicitation answers as `content`.
One terminal fact per reconnect. The demo server snapshots after the
close rather than before it, so requests the close already cancelled are
not replayed into the driver's stale-request recovery path and reported
terminal a second time. Reading afterwards also carries the closing
events' source sequence into the resumed session.
Goal support retired only on a provider denial. A transport or protocol
failure during `thread/goal/get` said nothing about what the build
supports but still set `goals: false`. `CodexRpcError` now carries the
JSON-RPC code, and the capability is retired only when the provider
answers that it will not serve the method.
Three defects surfaced while verifying the above are fixed here too: a
same-origin `EventSource` GET sends no `Origin`, so requiring one on
`/stream` rejected the console's own subscription and no live-console
test could connect; the browser payload redactor covered only
`.paperclip` paths and leaked the app-server's `~/.codex/memories`; and
the browser suite shares one server across 19 sessions against an
interactive cap of 16, now sized through `PAPERCLIP_PHASE4B_MAX_SESSIONS`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add the package-local browser tracer over the Phase 4b protocol boundary as a
new Live console mode in the standalone devtool.
Surfaces derive only from canonical PRP events and the shared reducer: live
transcript and composer, same-turn steering with stale-turn recovery, three
distinct interrupt races, inline runtime request cards, capability-gated goal
controls, parent/child lineage, reconnect, refresh, replay, and a redacted
protocol inspector.
Add a deterministic scripted driver and eleven demo chats behind the same demo
server routes the real Codex driver uses, so every protocol state is reachable
without a provider account and PAPERCLIP_PHASE4B_DRIVER=codex swaps in the real
session.
Adapt shadcn/ui and Vercel AI Elements source with zero new runtime
dependencies, and extend the boundary check to keep it that way.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
