# Three-scenario continuity protocol

Version 1.0.1 · October 3, 2026 · Proposed protocol; all runtime trials NOT_RUN

Purpose: distinguish a documented product boundary, a discovery problem and a reproduced cross-client defect. Expected effort: approximately 15–25 minutes for an eligible, preconfigured account; this is a planning estimate.

## Prerequisites and evidence

Use the same account/workspace on web and desktop. Record exact web route, client/host version, mode, execution environment, timestamp, account eligibility and relevant policy restrictions. Use harmless disposable context. Keep this record private until evidence is reviewed for publication.

For every trial record: trial ID, objective, setup, source contract, actions, expected behavior, observed behavior, exact object IDs if exposed, screenshot references, start/end time, status and limitations. Do not collect credentials, private transcript bodies, raw memories or unrelated account history. Public screenshots should show only the relevant controls or disposable task.

Statuses: **PASS** means the declared contract was observed; **FAIL** means it was contradicted in a valid trial; **INCONCLUSIVE** means evidence cannot decide; **NOT_RUN** means it was not executed; **NOT_APPLICABLE** means a documented eligibility or capability restriction excludes the case. A product boundary can produce friction without being a failed contract.

## T1 — Find and resume the same work

1. Select one pre-existing, harmless conversation with a documented continuation route. Record whether it is Work, local Codex or Codex Cloud; record its stable link/ID if exposed. Do not start from a shared snapshot and assume it is live.
2. From the other client, locate the item through the supported history/project/remote path. Record elapsed time, labels, required steps and whether the computer must be reachable.
3. Confirm the object identity, ownership, last visible turn and available context. If eligible, append the harmless marker `continuity check T1` once and confirm it appears in the other client. Record the acknowledged result before any retry.
4. If the object is local-private or the route is unsupported, record the restriction and whether the interface explains it. Do not upload its history to manufacture parity.

**Contract check:** an eligible live continuation preserves identity and authorized history; a snapshot is clearly read-only. **Design measure:** find-and-resume time and ability to explain unavailable cases. Do not claim sync failure from an absent unsupported entry.

## T2 — Explain the effective profile

1. Inspect the current web controls and local diagnostics for a harmless comparable task. Where supported, use `/status` and `/debug-config` to identify local configuration layers. Read only; do not change settings or expose secret-containing config.
2. Record visible supported fields: model, mode, personality/style, personal/project instruction source, memory scope, approvals and enforced requirements. Mark unavailable fields unknown.
3. Submit the same harmless prompt in disposable sessions: `Explain how to organize three notes into a project in five sentences.` Record response text privately and the effective fields separately.
4. Explain each difference with a documented source or mark its cause unresolved. Do not treat model wording variance as proof of settings failure.

**Contract check:** supported diagnostic sources agree with their documented scope. **Design measure:** whether the operator can explain which inputs apply and why. Universal Codex Cloud personality or memory inheritance must not be assumed.

## T3 — Recover a disconnected computer

Use only an already-enabled, supported Work Sync/local-access setup and a disposable read-only task. Do not change security grants, workspace policy or device networking to enroll the account. If unavailable, record NOT_APPLICABLE or NOT_RUN.

1. Start a read-only operation against a temporary fixture through the supported local-access path. Record the run target and accepted command before simulating loss of host reachability.
2. In an isolated fixture with an explicit safe disconnect method, temporarily make only that test host unavailable. Do not disable the real device's network or interrupt unrelated work. If no isolation exists, stop the trial and record NOT_RUN.
3. Observe the web status. Record whether observations become stale, whether the item waits for the named computer, and whether a missing response is treated as unknown. Do not press Retry while the original command's result is uncertain.
4. Restore fixture reachability and inspect recovered receipts/output and task identity. Record whether the original action completed, failed or remains unresolved. Confirm that recovery did not silently create an additional attempt.

**Contract check:** compare with the documented eligible Work Sync path and distinguish offline from revoked access. **Design measure:** clarity and time to reconcile state. This read-only trial cannot prove duplicate prevention for external writes, instant cancellation or universal exactly-once execution.

## Result template

```text
Trial ID / date:
Account/workspace eligibility (private):
Web route / desktop version / mode:
Object identity / target / continuity class:
Source contract:
Exact actions:
Expected documented behavior:
Observed behavior:
Evidence references and timestamps:
Result: PASS | FAIL | INCONCLUSIVE | NOT_RUN | NOT_APPLICABLE
User friction even if contract passes:
Limits / competing explanation / next check:
Publication review: private | reviewed public-safe
```

Keep failed and contrary results. Repeated trials require the same setup or a recorded change. These checks do not test OpenAI's private architecture or validate the proposed release targets.

Evidence state for the unexecuted runtime trials is **AWAITING_LOCAL_RUN**. **NOT_RUN**, **PASS** and **FAIL** describe execution or a trial verdict, and do not replace canonical evidence states.