DottaandClaude
3fdcc2a28c
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A native ACPX run (for example Claude) sends `turn.start` to its Runner. The Runner asks the ACPX sidecar to start the turn, and the sidecar sends the prompt to the provider > - A start can fail without a definite answer. A host freeze can outlast the sidecar request deadline, or the sidecar or Runner can die during the start > - The Runner then saved the session `closed`. Every same-run resume failed with `ACPX session is not open`, and the task needed Retry > - The Runner cannot tell from its own state whether the provider has the prompt. Resending could duplicate it. A continuation could lose it > - This pull request adds a durable record that answers that question: a sidecar prompt-dispatch journal, written before the prompt reaches the provider > - The benefit is that a start cut off before the prompt left resends the prompt exactly once, with no Retry. Every case the record cannot prove keeps today's behavior ## Linked Issues or Issue Description **What happened?** Local restart-chaos wave `w-20261110T185315-s9107`, task t05 (claude, workload C1, fault TM2). A follow-up run reopened the parked Claude session and sent `turn.start`. The sidecar first starts Claude and loads the conversation; the prompt goes out only after that. After 24 s without a reply, the harness froze the server, Runner, sidecar and Claude (SIGSTOP) for 33 s. On thaw the Runner's 30 s sidecar deadline had passed. It reaped the sidecar and saved the session `closed`. Three same-run resumes failed with `PRP command turn.start failed: … ACPX session is not open`, recovery stopped with `native_session_retry_exhausted`, and a person had to click Retry. **Expected behavior** When a durable record proves the prompt never reached the provider, the run resends it once by itself. When the record cannot prove it, the run behaves as today. **Steps to reproduce** 1. On master, run `cargo test --manifest-path packages/paperclip-runner/runner/Cargo.toml -p paperclip-runner-core --test acpx_park_preparation cut_turn_start`. 2. `a_start_cut_off_before_the_prompt_left_reopens_and_sends_the_prompt_once` fails: the session is `closed` and the next start fails with `ACPX session is not open`. Refs #20507, #20645, #20674 ## What Changed - New file contract in `protocol/provider-schemas/acpx-sidecar.schema.json`: `turnDispatchJournalFile` (`paperclip-turn-dispatch.jsonl`) and `turnDispatchJournalRecord` (`received` / `dispatched`). The generator emits the file name and schema into TypeScript and Rust, so the pack contract digest covers them. - Sidecar (`turn-dispatch-journal.ts`, `codex-runtime-adapter.ts`, `runtime-host.ts`, `acpx-runtime-sidecar.ts`): when the runtime port starts a turn, before any provider work, it truncates the journal and writes `received`. ACPX calls `onAcpMessage("outbound")` synchronously before it writes a message to the provider. On the turn's first `session/prompt` request the port appends `dispatched` and fsyncs it there, so the record exists before the bytes leave. A failed dispatch write aborts the prompt write. A failed `received` write removes the file and runs the turn unjournaled. - Runner (`acpx_turn_dispatch.rs`, `acpx_provider_backend.rs`): the journal is read only after the provider lifetime fence proves that the sidecar and provider are gone. A lone complete `received` record for the turn proves the prompt never left. - A start that failed in flight saves the session `prepared` with no active turn and returns `ACPX turn start failed before its prompt reached the provider`. The run's next `turn.start` reopens the conversation and sends the prompt once. Until the proof settles, the saved state stays `turn_starting`, so a Runner killed during the proof goes through the restore check below. - A Runner killed while the session was `turn_starting` restores the session idle (`session.resumed`, no `turn.failed`). The same-run resume then starts the turn once instead of sending a continuation that would lose the prompt. - A `dispatched` record, another turn's record, a torn or malformed file, or no file keeps today's behavior (closed session, or lost-turn recovery). - Fake sidecar: writes the same journal and adds `hang-before-dispatch` / `hang-after-dispatch` faults. - Docs: `packages/paperclip-runner/docs/durable-recovery.md` ("ACPX turn starts cut off before the prompt left"). The design note is `doc/plans/2026-11-10-durable-turn-start-and-tool-call-records.md` (in #20674). ## Verification - Red on master, green here: `cargo test -p paperclip-runner-core --test acpx_park_preparation cut_turn_start` (4 tests: cut before dispatch reopens and sends once; cut after dispatch stays closed and never resends; Runner killed before dispatch restores idle; Runner killed after dispatch or with no journal reports the lost turn). The two "before" cases fail on master. - `cargo test -p paperclip-runner-core`: all pass. `cargo fmt --check` clean. - `pnpm --filter @paperclipai/paperclip-runner exec vitest run src/drivers/acpx/turn-dispatch-journal.test.ts src/drivers/acpx/codex-runtime-adapter.test.ts`: 121 passed. One test uses a real ACPX runtime and an ACP peer that refuses a prompt arriving before its `dispatched` record; it fails if the hook is removed. - `node scripts/generate-acpx-sidecar-contract.mjs --check`, `node --test scripts/contracts/contract-fingerprints.test.mjs`, and `tsc -p tsconfig.test.json` pass. - Time to first token, measured with the same open/write/fsync sequence on this Mac (APFS, load average ~11, 300 samples): `received` p50 0.24 ms, p95 0.59 ms; `dispatched` (with fsync) p50 4.7 ms, p95 11.5 ms. Against a Claude TTFT budget of 9.5–16.5 s p50 this is under 0.1%. No wait, round trip or file transfer is added. Recovery work (fence, journal read) runs only after a failed start. - Live restart-chaos wave and runner image: see the comments on this pull request. ## Risks - A false "not dispatched" proof would duplicate a prompt. It needs a lone, complete `received` record for this exact turn ID, read after the fence proves the sidecar is gone. `dispatched` is fsynced before the prompt write, and a failed write aborts the send. A failed `received` write removes the file, so it cannot leave a lone record. - Upgrade safety: saved provider state gains no field (its decoder denies unknown fields), and only lifecycles an older Runner already handles are written. An older Runner ignores the journal file. State saved by an older Runner has no journal, which reads as unknown and keeps today's behavior. A new Runner with an older sidecar never sees a `received` record, so no proof forms. - The changed sidecar schema changes the pack contract digest, so Daytona needs a new runner image. Older image packs are not reused. - A failed start now waits for the provider lifetime fence (at most 5 s, usually immediate) before it settles. This is only on a failure path. ## Model Used Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, with tool use (shell, file editing) in Claude Code. Extended reasoning was used. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude <noreply@anthropic.com>
PRP v1/v2 Contract
The JSON Schema files in schemas/ are the language-neutral source of truth for
Paperclip Runner Protocol versions 1 and 2. The fixtures in fixtures/ define
accepted and rejected compatibility cases.
Compatibility
protocolVersion,fixtureVersion, andevent.schemaVersionare required.- A consumer fails closed when a required version or schema discriminator is not supported.
- A v1 envelope can contain an unknown optional property when its schema marks that object as extensible.
- A consumer ignores an unknown optional property until a later contract gives it meaning.
- A required field, enum value, or typed structured-input field is not optional.
- Question and answer identifiers are stable across the provider boundary.
- Peers negotiate the highest mutually supported protocol version. Existing v1 runners remain compatible but cannot receive v2-only session-goal commands.
The unknown-optional-fields.json fixture must be accepted. The
unsupported-required-version.json fixture must be rejected.
Session goals (v2)
PRP v2 adds a provider-neutral durable session-goal lifecycle. Every v2
capability snapshot includes sessionGoals, even when its availability is
unsupported or policy_disabled. Paperclip sends controls only when the
negotiated capability advertises the corresponding action.
Commands:
session.goal.getsession.goal.setfor objective, status, and optional token budget changessession.goal.clear
Events:
session.capabilities.updatedsession.goal.snapshotsession.goal.updatedsession.goal.cleared
Goal state is separate from Paperclip's company/business goal hierarchy. The
snapshot distinguishes the durable status from workingNow, because an active
goal can be idle between autonomous turns. A runner emits the full capability
and authoritative snapshot after every session open or resume. Missing v1
capability is unsupported; clients do not infer support from an adapter name.
Harness credential updates
auth.credentials.updated is a P0 runner event available in the v1, v2, and v3 event
schemas. Its payload uses paperclip.auth.credentials.updated.v1 and contains
only provider, bindingId, revision, and detection. No tokens, account
identifiers, credential paths, or credential fingerprints are permitted.
An updated consumer opts in with observeCredentials: true in run.prepare,
before session.open. The bundled runner transport opts in for fresh sessions;
set its observeCredentials option to false to disable observation for a
fresh session. Older hosts that omit the field receive no new event. Consumers
must update their schemas before opting in: an event-enum addition is not an
unknown optional property. Existing runner binaries ignore the optional flag
and do not provide observation; absence of an event does not establish support.
The current Unix runner observes native Codex's managed CODEX_HOME/auth.json
and the Codex/Grok ACPX session homes. It uses a non-recursive directory watch
plus a one-second polling fallback, so atomic file replacement is handled.
Grok's initial inline subscription credential is the baseline, allowing a
refresh during launcher startup to be detected. A first valid credential file
without a prior baseline establishes the baseline without claiming a refresh.
Account identity changes also emit updates, even when token values stay the
same, and establish the baseline for later refreshes on the new account.
Hosts must evaluate the current credential through their private credential
channel and account checks; the event does not authorize an account switch.
Metadata-only changes, partial writes, and deletion do not emit updates.
Unsupported harnesses and refreshes retained only in memory need
their own observer or native-hook integration; adding this event does not make
them observable.
bindingId: "harness-auth" identifies the selected harness authentication
within the envelope's normalized session. Revisions increase for that binding
and survive runner restarts and warm run attachments. The baseline fingerprint
and pending event are persisted together in a private runner state file. Source
retries retain the same event identity until the durable PRP outbox accepts it.
Hosts should commit an idempotent reaction or durable work item through
onCommittedEvent before returning and advancing the cumulative ACK.
The bundled transport exposes onCredentialsUpdated(event) for this commit.
It awaits the callback before ACK, including during warm idle, attachment, and
provider cleanup. Callback failures leave delivery unacknowledged for retry;
callbacks must therefore deduplicate by the original source event identity.
When configured, credential updates bypass the turn notification queue.
Paperclip commits them directly to the run log in a separate credential source
namespace, preserving the original PRP envelope and avoiding collisions with
the driver's normalized event sequence. A turn-only notification consumer
cannot reliably handle idle or cleanup updates; use this callback instead.
detection: "credential_store" reports an observed credential change, not proof
that an OAuth refresh succeeded. Multiple changes between observations can be
coalesced; this is not an audit of every refresh exchange. The schema also
allows native_hook for integrations with an explicit signal. Observation
continues during warm idle and checks at turn terminal and close boundaries,
including Grok's private refresh handoff after live-store cleanup. Retained
runner observations enter the durable outbox before a suspend or shutdown
command completes, without draining the provider backlog. A final check after
provider cleanup also enters the outbox and waits for the host ACK. The runner
retains its terminal recovery fence if that delivery fails.
The event authorizes no credential access or write on its own. A host that needs rotated token values must use a separately authorized handoff with its existing account-identity and freshness safeguards. The default Paperclip credential copy-back behavior remains in place.
Scope
The first provider descriptor and adapter fixture cover Codex only. The schemas for provider-neutral events and semantic receipts do not enable those actions. Discovery and authorization are separate contracts.
The conformance manifest records every source file and its SHA-256 digest. Run
pnpm generate:protocol-manifest from this package after a source change. CI
runs the same generator with --check to reject drift. This check also compiles
the JSON Schemas and validates every replay, question, and cross-language
conformance fixture against its declared schema.
The files in fixtures/replay/golden/ are deterministic reducer oracles. Each
accepted replay fixture has a complete session snapshot and a compact parity
summary. pnpm generate:replay-goldens updates them after an intentional
reducer change; package build and CI fail when they drift.
The files in fixtures/local-runner/scripts/ drive the package-local fake
harness. They cover successful, failed, interrupted, interactive, duplicate
terminal, process-cleanup, and oversized-frame behavior without starting a
production adapter.
runtime.activity.recorded is a P1 Runner event in v1, v2 and v3 with exactly
{ namespace, activityKey }. Both opaque identifiers contain 1–160 Unicode code
points and exclude C0 controls and DEL. namespace groups a producer's activity
types; activityKey names an activity within that group. Consumers use the pair
to select a response to activity in the run. The authenticated outer envelope
provides run and session identity, source sequence and emission time. Core resolves
the run's company, task and agent through its existing authorized run binding;
callers cannot supply those identities in the payload. Recording activity does
not independently verify the reported action or grant access to any resource.
The event uses the ordinary durable outbox, acknowledgement and replay contract.
Local clients capture an opaque context with paperclip-runnerd notification-context
before an operation and invoke record-activity CONTEXT NAMESPACE ACTIVITY_KEY
after success. Runner publishes its matching absolute executable as host-owned
PAPERCLIP_RUNTIME_NOTIFICATION_HELPER and the stable endpoint descriptor path
as PAPERCLIP_RUNTIME_NOTIFICATION_CONTEXT. Configured task environment cannot
override either value. Context is invalidated on warm attachment and process
recovery, so a caller cannot attribute a later completion to a different run.