DHF Runtime Promotion / Seven Protected Targets

PROTECT: Seven Protected DHF Runtime Components

These are not seven WALs. One fsync-backed WAL transaction promotes seven cooperating runtime components together. If any target fails, the whole promotion is restored in reverse order.

1 WAL transaction → 7 protected targets → 1 verified runtime state

Memory model

Position, restrict, observe, and thread the work; empower the owner, contain impact, and transact the release.

PPosition

RRestrict

OObserve

TThread

EEmpower

CContain

TTransact

Seven components / WHY · WHAT · HOW

Each component closes a different control gap

Position

Know where the task is

WHY: Without a reliable stage, the system cannot distinguish valid progress from an unauthorized jump.
WHAT: Resolve task phase, durable state, and recovery facts.
HOW: Compute phase from durable task and session evidence; uncertainty falls back conservatively.

codex/hooks/task_state.py

Restrict

Stop actions that should not happen

WHY: Prompt guidance can advise an agent, but cannot enforce a business boundary.
WHAT: Allow or block before execution using phase, risk, roots, and authorization.
HOW: PreToolUse loads position and scope, then fails closed for unsafe actions.

codex/hooks/harness_guard.py

Observe

Make outcomes independently checkable

WHY: Without post-execution facts, “done” is only an agent's assertion.
WHAT: Capture real outcomes as recoverable, auditable evidence.
HOW: PostToolUse records decisions and results without treating observation as authorization.

codex/hooks/harness_observer.py

Thread

Keep work continuous across sessions

WHY: Session loss or compaction can erase business context and trigger duplicate work.
WHAT: Restore task bearing, boundaries, and the next safe action.
HOW: SessionStart reads durable state; recovery does not expand permissions.

codex/hooks/session_bearing.py

Empower

Give the accountable owner an explicit control

WHY: Implicit authority is hard to audit and easy for stale sessions to reuse.
WHAT: Declare, inspect, and revoke time-bounded phase capability.
HOW: The owner uses a CLI to create TTL-bound phase declarations.

codex/bin/codex-task

Contain

Limit the blast radius

WHY: A reasonable action in the wrong directory can still create an incident.
WHAT: Declare governed roots, protected roots, and allowed scope.
HOW: The guard reads explicit configuration; the harness installation stays protected.

codex/runtime/harness-scope.json

Transact

Promote all seven together or restore all seven

WHY: A partial update creates a mixed runtime with incompatible control components.
WHAT: Fix the seven-target set and journal intent, application, and final commit.
HOW: Atomically replace and fsync each target; restore in reverse on failure.

codex/runtime/harness-guard-targets.json + scripts/sync_codex_home.sh

Business collaboration

How the seven protect one business action

1 · ThreadRestore session bearing

2 · PositionResolve the phase

3 · ContainLoad governed scope

4 · RestrictGate before execution

5 · ObserveRecord after execution

Empower is the accountable owner's authorization control. Transact is the outer release envelope that safely installs the entire control plane.

One WAL / Atomic promotion

The WAL protects runtime consistency, not file copying

Back up seven targets

Write PREPARED

Journal each INTENT

Atomic replace + APPLIED

Verify manifest and policy

COMMITTED or ABORTED

harness/deployed-manifest.json is also captured for rollback, but it is a deployment receipt—not one of the seven formal promotion targets.

Evidence boundary

This page explains the design; it does not prove the latest source is active

The 24/24 parity and 18/18 isolated host probes from 2026-08-10 prove only the snapshot promoted at that time. Later source changes still require a new authorized promotion, full verification, and runtime readback.