Follow-up: typed, evidence-aware CrossThreadEvent contract for safe peer-thread orchestration

Summary

Cross-thread primitives (list, read, send, fork, archive) have shipped and #14923 is complete. This follow-up proposes a narrow safety and interoperability layer for messages exchanged between durable Codex threads.

The core distinction is:

message delivered
!= statement verified
!= state accepted
!= action authorized

A receiving thread should not treat unstructured cross-thread prose as verified state or as permission to execute an action.

Problem

A durable orchestrator may receive messages such as:

• "deployment succeeded"
• "tests passed"
• "use this endpoint"
• "release the lock and continue"

Today, the transport can deliver such information, but the receiver still needs a reliable way to determine:

• which thread and agent produced it;
• which task trajectory it belongs to;
• whether it is a question, observation, result, state update, or action request;
• which evidence supports it;
• whether it supersedes earlier state;
• whether the sender may inform, request an action, or authorize execution.

Without this separation, successful message delivery can be confused with verification or authority.

Proposed minimal contract

Introduce an optional typed envelope for cross-thread messages, tentatively CrossThreadEvent:

{
  "schema_version": "cross-thread-event/v0.1",
  "event_id": "evt-2026-001",
  "trajectory_id": "project:migration",
  "continuation_id": "thread-infra-04",
  "source": {
    "thread_id": "thread-infra",
    "agent_id": "agent-infra",
    "role": "infrastructure"
  },
  "target": {
    "thread_id": "thread-application"
  },
  "event_type": "STATE_UPDATE",
  "subject": "deployment.endpoint",
  "payload": {
    "value": "https://new-endpoint.example"
  },
  "evidence_refs": [
    "tool-event:health-check-883",
    "artifact:deployment-report"
  ],
  "verification_status": "VERIFIED",
  "authority": {
    "may_inform": true,
    "may_request_action": true,
    "may_authorize_execution": false
  }
}

This can coexist with plain-text messaging. The typed form is for state transfer, handoffs, blockers, completion reports, and action requests where provenance and authority matter.

Receiver processing model

A receiving thread should process a typed event through explicit stages:

receive
-> authenticate source
-> validate trajectory and scope
-> inspect evidence references
-> detect stale or conflicting state
-> accept / reject / defer
-> propose local action
-> normal approval, sandbox, and execution path

Core invariants

1. Cross-thread communication may inform reasoning, but must not silently bypass the receiving thread's approval, sandbox, or execution policy.
2. Delivery status is distinct from verification status.
3. A sender may request an action without being allowed to authorize it.
4. Stale state must not overwrite newer accepted state.
5. Duplicate event delivery must be idempotent by event_id.
6. Archived or capability-revoked threads must not continue sending accepted events.
7. Both source and target should retain an auditable record of the event and its disposition.

Capability shape

A capability grant could remain operation- and event-type-specific:

{
  "capability": "send_message_to_thread",
  "source_thread": "thread-A",
  "target_thread": "thread-B",
  "allowed_event_types": ["QUESTION", "STATE_UPDATE", "RESULT"],
  "requires_target_consent": true,
  "expires_at": "2026-12-31T00:00:00Z"
}

Conformance / acceptance cases

A small deterministic fixture could verify:

• orchestration is disabled or permission-gated by default;
• thread A cannot read thread B without a granted capability;
• one message appears in both source and target audit trails;
• an unverified state update does not release a dependent task;
• a stale event cannot overwrite newer accepted state;
• replaying the same event_id is idempotent;
• the sender can request an action but cannot authorize execution unless explicitly granted;
• model, reasoning, sandbox, and approval overrides remain visible and attributable;
• archived or revoked threads cannot continue sending accepted events;
• resumed threads preserve trajectory identity and event history.

Non-goals

• Replacing existing plain-text cross-thread messaging.
• Making Codex an implicit lock authority.
• Automatically trusting evidence references.
• Allowing peer threads to bypass existing user approvals or sandbox policy.

Why this is a separate follow-up

#14923 asked for durable cross-thread orchestration and that transport layer has shipped. This issue is specifically about making state transfer and action requests typed, evidence-aware, permissioned, and auditable on top of those primitives.

cd prototypes/openai-agent-trust-runtime
python3.11 -m venv .venv
. .venv/bin/activate
python -m pip install -e '.[dev]'
pytest
ls-cross-thread-conformance
ls-cross-thread-demo