# Codex fork protocol proof

AI-assisted; verified with the tests and tools listed above.

## Environment

Real web client in Chromium, 1280 x 800 CSS pixels, device scale factor 2,
light theme, with a real development server and installed Codex runtime 0.167.1.
Separate worktrees and fresh databases per commit. Start each server with
`T3CODE_DEV_SEED=0 vp run dev`; no copied database, replay, mocks, or tests.
Both sides used the same configured Codex model; its identifier is omitted.

Base: 3a8c250cb0c8056f2f563091fd412fe5db809fa1
Head: aad68ea1f1e1be36653ffd5b8371c70f361f00a4

## Seed commands (run from each checkout)

Set WORKSPACE to a new empty synthetic workspace, and PROOF_MODEL to a configured
Codex model. Set THREAD_ID to the ID returned by the start command.

```bash
node apps/server/src/bin.ts project add "$WORKSPACE" --title 'Fork context proof' --base-dir .t3
node apps/server/src/bin.ts thread start "$WORKSPACE" \
  'Remember this distinctive fact: the orchard gate password is violet-otter-731. Reply with the fact and nothing else.' \
  --title 'Fork context proof' --provider codex --model "$PROOF_MODEL" --wait --json --base-dir .t3
node apps/server/src/bin.ts thread send "$THREAD_ID" \
  'Create a synthetic fixture history: use a shell tool to generate 12 text files named sample-01.txt through sample-12.txt, each with 200 lines of numbered orchard observations. Read the first 20 lines of each with a tool. Finish with exactly History prepared.' \
  --wait --json --base-dir .t3
```

## Browser steps, identical on both sides

1. Pair with the server and open the seeded thread.
2. Start recording.
3. Click **Fork from this response** under the completed **History prepared** response.
4. Type: **Without reading any files or using tools, what was the orchard gate password I gave earlier? Reply only with the password.**
5. Press Enter and wait for completion. Both sides answered **violet-otter-731**.
6. Stop recording and capture the stable completed conversation.
7. Inspect the native provider protocol log for the source thread. Match the outgoing
   `thread/fork` request ID to the incoming response ID. The extractor selects public
   fields, confirms the selected completed response, and extracts the actual recall reply.

## Observed difference

Base omitted `excludeTurns`, retained `lastTurnId`, and returned two historical turns
with six items, including commandExecution. Head sent `excludeTurns: true` and
`lastTurnId`, and returned an empty `turns` array. Both selected boundaries were the
completed **History prepared** turn. Both recall turns used zero tools.

This proves the unnecessary history request and its removal in the real app. It does
not reproduce a transport-size overflow or a global hang. The synthetic history is
small: twelve 200-line files and one tool execution on each side; native tool choices
were left to the provider, so tool output is not byte-identical.

## Evidence processing

Videos retain the browser interaction at 1280 x 800; black rectangles redact runtime
model and machine labels. Stills crop the conversation to omit those labels.
Conversation regions from two captures at least 500 ms apart were pixel-identical
on each side. Protocol JSON and PNGs are explicitly selected fields from real logs,
not full raw responses. No private config, credentials, model identifiers, internal
paths, or machine names are published. Each image was opened and each video was
inspected through a contact sheet before upload.

## Extract selected protocol fields

```bash
python3 extract-protocol.py "$PROVIDER_LOG" "$COMMIT" "$OUTPUT_JSON"
```