v0.2.0-beta.7 — First-run recovery improvements

v0.2.0-beta.7

Summary

FIRST_RUN_RECOVERY_BATCH is one consolidated milestone that reduces first-run
and recovery friction while preserving CRA's human-controlled, read-only safety
model. CRA remains EXPERIMENTAL with ACTIVE_BEST_EFFORT (ACTIVE - BEST
EFFORT) maintenance. Evidence comes before conclusions.

These notes describe the beta.7 scope, not publication status. The
GitHub Releases page
is authoritative for actual publication. Passing acceptance gates does not
establish stable support, production readiness, universal compatibility, zero
defects or automatic root-cause detection. This remains a beta, not an RC.

What changed

The milestone combines six user-facing improvements:

1. Safe Skill conflict/replacement recovery.
2. Same-request STEP 2 typo correction.
3. Copy-safe launch.
4. OutputDirectory recovery guidance.
5. Direct AI safe-reader happy path.
6. Safe request-context reuse.

First-run / Skill recovery

Setup distinguishes ABSENT, IDENTICAL and DIFFERENT installed content.
ABSENT uses authorized installation and hash verification; IDENTICAL needs no
replacement. DIFFERENT never permits silent overwrite or guessed provenance.
The operator explicitly authorizes the source and destination, then setup:

• backs up existing content outside active Skill discovery roots and verifies
  the backup hash;
• immediately rechecks source and destination against the authorized hashes;
• replaces only the authorized destination and verifies its post-copy hash; and
• reloads or starts a new conversation where required, confirming recognition
  and matching loaded instructions before observation.

Use the Skill, bridge and runtime from the same checkout. Follow the
first-run setup procedure.

STEP 2 same-request correction

Invalid STRING review input may be corrected within the same IncidentOnly /
PassThru request before review acceptance. The human resubmits the complete
review set or cancels. This is not a generic retry engine.

Rejection is atomic: nothing is accepted and no partial candidate selection is
retained. The same discovery, OutputDirectory, request_id and candidate_set_id
remain active. No review artifact is published before valid acceptance; STEP 2
is not re-entered after acceptance. There is no automatic retry or rediscovery.

No target ranking, target recommendation, automatic target selection, candidate
model change, artifact schema change or extra capture is introduced. Fresh O0
remains required after the human selects a target and chooses Observe. Manual
Guided / Session / Finder behavior and delivery-failure semantics are unchanged.

Launch and OutputDirectory recovery

The operator launches locally in their own PowerShell 7 console. Codex supplies
literal assignments for the validated actual repository path and agreed fresh
destination; it does not automatically launch CRA. After setting those variables
and clearing stale receipt state for a genuinely new invocation, use:

$receipt = & (Join-Path $RepoRoot 'scripts\Invoke-CraAiBridge.ps1') `
  -OutputDirectory $OutputDirectory

See the canonical launch procedure.
Do not clear the receipt or replace active context during same-request correction.

A successfully created request directory belongs permanently to that request,
including after cancellation or failure. It is not reused for another observation.
CRA_AI_DESTINATION_EXISTS means the attempted new invocation did not begin a
new observation. A genuinely new observation requires a fresh directory, fresh
IDs, fresh discovery and new human choices; preserve the old request's context.
STEP 2 correction keeps the same request, directory and IDs. There is no automatic
cleanup or cross-run context mixing.

AI safe-reader / context reuse

When supported local execution/file capability exists, a capable AI client can
use CRA's existing safe reader directly with explicit expected context. The
operator normally needs no manual JSON parsing, raw-artifact pasting, private
process-table pasting or manual Format-Table of observed_context.

Capabilities differ across clients and environments. A client without the needed
capability must disclose that limitation instead of pretending validation
succeeded. Reader rejection stops interpretation; raw JSON is not a fallback.

The safe tuple (OutputDirectory, request_id, candidate_set_id) is normally
supplied once and reused only within the same explicit request. Ask again only
when it is missing, ambiguous, stale or mismatched. IDs provide correlation, never
authentication or authorization.

Validation

Product implementation acceptance belongs specifically to commit
996996e58056245e8784e4db3dc7abd248f407e9:

• Local full offline suite: 1900/1900 PASS.
• Exact-SHA Hosted Windows CI, run 35838624062: 1900/1900 PASS.
• Both test runs: zero failed, skipped, inconclusive or not-run tests.
• Gates 1–5: PASS. Human clean-clone acceptance is Robin-reported PASS,
  covering authorized Skill replacement, matching loaded Skill, actual-path
  launch, same-request STEP 2 typo correction, direct safe-reader operation and
  fresh-request recovery with old context preserved.

At the documentation-preparation checkpoint on 2026-09-23, this documentation-only
change was an uncommitted working-tree diff. The product commit above is not a
claim about a later release-target SHA. Its original Hosted CI and human acceptance
must not be relabeled as testing subsequent documentation bytes. The exact final
target requires its own applicable review and validation under the
release policy.

The current executable-vector disclosure
remains:

• Positive executable: 22/22.
• Negative executable: 37/38.
• N30: PARTIAL — NO_EXISTING_T18_1_RUNTIME_SEAM.

N30 remains a non-executable design boundary; this milestone does not implement
the missing T18.1 runtime seam or change the standalone CPU Activity Check scope.

Retained safety boundaries

CRA remains read-only. Humans own the review set, target selection, Observe, O1,
ACTIVITY_END and all other confirmation gates. There is no kill, cleanup, restart,
remediation, automatic target choice or bad-process classifier.

• Evidence before conclusions; UNKNOWN != CODEX.
• Candidate/readiness != VERIFIED_ROOT; ownership stays UNKNOWN unless established.
• NEWLY_OBSERVED != created by the activity.
• NO_LONGER_OBSERVED != process exit.
• PRESENT at O3 != residue, orphan or leak.
• Parent-child != ownership or causation.
• Working set != task cost or memory leak.
• COMPLETED != task solved.
• Same PID alone != exact identity.

Incident-derived ownership remains UNKNOWN. Missing, ambiguous or contradictory
evidence does not authorize stronger conclusions, process control or extra captures.

Known non-blocking friction

STEP2_TYPO_UX = FRICTION is non-blocking. Same-request correction passed
acceptance without a full rerun. External first-run testing should determine
whether this or other friction warrants follow-up; minor wording/friction belongs
in the backlog rather than an immediate product patch.

Historical note

The unchanged annotated v0.2.0-beta.5 tag targets commit
9ebb713bacac36c85474eb6869eef8d02198daad; no GitHub Release was published for it.
It was superseded in the development sequence and must not be deleted, moved,
retargeted or retroactively published. Beta.6 was the published predecessor at
the beta.7 preparation checkpoint and contained the display-only STEP 2 guidance
correction. Historical releases and their validation retain their original scope.

External testing next

After publication, invite 3–5 genuinely unfamiliar Windows Codex users to
try the first-run flow. No feature expansion comes first. Collect STOPs, guesses,
repeated friction, safe-reader capability issues, Skill replacement friction,
STEP 2 confusion and OutputDirectory recovery confusion before immediately patching.

Prioritize a rapid follow-up only for a runtime defect, safety defect,
artifact/contract defect, genuine first-run STOP or repeated serious usability
blocker. Accumulate minor wording and usability friction in the backlog.

v0.2.0-beta.6 — Clearer STEP 2 review guidance

v0.2.0-beta.6 release notes

CRA remains EXPERIMENTAL with ACTIVE - BEST EFFORT maintenance. These
notes define the fixed v0.2.0-beta.6 scope. Their presence in a
checkout is not a publication claim; the
GitHub Releases page
is authoritative for publication state.

Theme: STEP 2 first-run operator guidance

This narrowly scoped correction follows real beta.4 human first-run testing and
the beta.5 publication-hold UX review. The beta.5 tag remains unchanged at
9ebb713bacac36c85474eb6869eef8d02198daad; it was not published as a GitHub
prerelease. Version v0.2.0-beta.6 contains the subsequent STEP 2
operator-display clarification described below.

The review found that STEP 2 already accepted multiple candidate IDs, while the
terminal guidance immediately before input was not explicit enough for a
first-time operator. STEP 2 now explains before input that:

• the operator is forming one review set, not choosing the final target;
• every candidate the human cannot yet rule out as relevant to the intended
  process or activity should be included, and same-name candidates may be
  reviewed together;
• STEP 3 compares that set using additional local identity information before
  STEP 4 asks the human to choose exactly one target from the review set; and
• candidates should not be trialed one-by-one merely to identify them, while
  Q/QUIT safely cancels when no meaningful review set can be formed.

Unchanged semantics and safety boundary

No review grammar, review-set semantics or target-selection semantics changed.
No candidate fields, candidate-model fields, comparison evidence fields, AI
artifact fields or private-field exposure were added. Candidate enumeration,
grouping, readiness and trust behavior are unchanged. Finder, Session, Incident
Observation and the CPU Activity Check are unchanged.

No automatic target selection, candidate ranking, review-set narrowing or AI
target choice was added. Human target selection remains mandatory at STEP 4;
review membership is not target selection, target selection is not
VERIFIED_ROOT, readiness is not a recommendation, and name, PID, group or
order does not establish ownership or identity.

This is an operator-display correction, not a new diagnostic capability. It
retains the beta.5 safe-handoff documentation and the existing privacy boundary.
Published beta.1 through beta.4 remain immutable with their recorded scopes,
while main remains moving development/latest source.

Validation baseline

The beta.5 tag checkpoint passed the full offline synthetic suite:
1859/1859 PASS, with zero failed, skipped, inconclusive or not-run tests. The
same exact checkpoint passed
Hosted Windows CI
with 1859/1859 PASS. These results identify the unpublished beta.5 tag
checkpoint; they do not make it a published prerelease.

Beta.6 adds one focused regression assertion for the pre-input STEP 2 guidance.
The complete offline synthetic suite passed 1860/1860, with zero failed,
skipped, inconclusive or not-run tests. This local preparation result establishes
no new Hosted CI, operator-validation or release result.

The retained executable-vector disclosures remain:

• positive executable vectors: 22/22;
• negative executable vectors: 37/38; and
• N30: PARTIAL because the corresponding T18.1 runtime integration seam
  does not exist.

v0.2.0-beta.4 — First-run target recognition guidance

v0.2.0-beta.4 release notes

CRA remains EXPERIMENTAL with ACTIVE - BEST EFFORT maintenance. These
notes define the intended fixed v0.2.0-beta.4 scope. Their presence in a
checkout is not a publication claim; the
GitHub Releases page
is authoritative for publication state.

Theme: First-run human-recognition guidance correction

A real beta.3 fresh-clone first-run test reached STEP 2 with multiple same-name
codex.exe candidates. The user correctly entered Q and cancelled rather than
guessing. That safe fail-closed result exposed a documentation gap: the first-run
guidance did not explain how review-set selection leads to local identity
comparison before final target selection.

Beta.4 clarifies that:

• STEP 2 chooses a review set, not the final target;
• all plausible same-name candidates may be placed in that review set;
• review membership does not authorize Observe or imply that a candidate is
  correct;
• STEP 3 presents local PID and Creation Time UTC evidence for comparison with
  independent current information about the intended process instance;
• STEP 4 is the human-owned target-selection point: the human chooses exactly one
  candidate from the STEP 2 review set. The choice is not VERIFIED_ROOT, and
  Codex does not choose or recommend it; and
• the human must cancel with Q rather than guess when recognition remains
  insufficient.

Codex may explain the safe candidate/review artifact fields and their limits, but
it cannot see the local PID/Creation Time comparison or choose the target. Human
target selection remains mandatory.

Unchanged runtime and safety boundary

No PowerShell runtime behavior changed. No candidate information, handoff field,
privacy allowlist or diagnostic capability was added. Beta.4 adds no automatic
selection, recommendation, ranking, anomaly classification, process control,
cleanup, remediation, Finder/Session change, CPU Activity Check change or T18
runtime change.

The AI-safe candidate artifact still omits PID, Creation Time UTC, executable
path, parent information, command line and user/session context. Process name,
READY state, candidate order, display group or PID alone cannot identify or
recommend a target. Creation time and parent-child evidence do not establish
ownership or causation.

Historical v0.2.0-beta.3 remains immutable with its original documentation-only
scope. Historical beta.1 and beta.2 likewise retain their recorded scopes. main
remains moving development/latest source; use the Skill, bridge and runtime from
the same fixed checkout.

Validation baseline

The retained Hosted Windows CI baseline remains 1859/1859 PASS, with zero
failed, skipped, inconclusive or not-run tests. The retained executable-vector
disclosures are:

• positive executable vectors: 22/22;
• negative executable vectors: 37/38; and
• N30: PARTIAL because there is NO_EXISTING_T18_1_RUNTIME_SEAM.

The beta.4 preparation reran the full offline synthetic suite: 1859/1859 PASS,
with zero failed, skipped, inconclusive or not-run tests. That local rerun is
separate from the retained Hosted Windows CI baseline. These results do not
establish production readiness, universal compatibility, a new diagnostic
capability or a support guarantee.

v0.2.0-beta.3 — First-run documentation correction

v0.2.0-beta.3 release notes

CRA remains EXPERIMENTAL with ACTIVE - BEST EFFORT maintenance. These
notes define the intended fixed v0.2.0-beta.3 scope. Their presence in a
checkout is not a publication claim; the
GitHub Releases page
is authoritative for publication state.

Theme: First-run documentation correction

This is a documentation-only correction to the beta.2 runtime. It fixes the
fixed-beta checkout guidance, makes the beginner Incident Observation entry point
prominent, and places advanced Finder, Session and T17/T18 terminology outside
the primary first-run decision path.

The README now makes these boundaries explicit:

• users arriving from the beta.3 Release use the matching
  v0.2.0-beta.3 checkout;
• main remains moving development/latest source;
• the Skill, bridge and runtime must come from the same checkout;
• CRA may present bounded candidates and evidence, but the human retains target
  selection and CRA does not decide which process is "bad";
• the first bridge command starts read-only evidence collection and does not kill,
  suspend, restart, clean up or modify processes; and
• CPU Activity Check is a separate bounded diagnostic for one process the human
  already selected independently, not the universal first step.

No runtime behavior changed from beta.2. CPU Activity Check capability and CPU
semantics are unchanged. This documentation correction adds no functional
capability, automatic target selection, process control, cleanup, remediation or
workflow expansion.

Historical v0.2.0-beta.2 remains immutable with its original target and
capability scope. Historical v0.2.0-beta.1 likewise retains its original T17
scope and does not gain the later CPU runtime.

Validation baseline

The beta.2 runtime validation baseline remains 1859/1859 PASS on Hosted
Windows, with zero failed, skipped, inconclusive or not-run tests. That remains
the runtime validation baseline unless a new exact-SHA Hosted Windows CI run is
subsequently produced for the beta.3 documentation checkpoint. A local offline
rerun during documentation preparation is reported separately and is not a
substitute for exact-SHA Hosted CI.

The retained executable-vector disclosures are:

• positive executable vectors: 22/22;
• negative executable vectors: 37/38; and
• N30: PARTIAL because there is NO_EXISTING_T18_1_RUNTIME_SEAM.

These results do not establish production readiness, universal compatibility or
a support guarantee.

Unchanged beta.2 capability boundary

The standalone T18.2A CPU Activity Check remains a human-gated, single-process,
read-only Windows diagnostic with an IN_MEMORY_ONLY result. It does not perform
automatic target discovery or selection, child/application aggregation, process
control, persistence, automatic AI upload, or T18.2B Memory Trend. Normal live
running cancellation remains NOT_EXPOSED.

CPU evidence does not prove root cause, Codex ownership, task cost, a memory leak,
residue/orphan state or problem resolution. Use the
CPU Activity Check guide for the unchanged operator
workflow, metric semantics and safety boundaries.

v0.2.0-beta.2 — Live-validated CPU Activity Check

Theme: Live-validated CPU Activity Check

This candidate adds the standalone T18.2A Windows CPU Activity Check to the
existing CRA workflows. A human independently supplies one current PID, reviews
separate bind and bound-target gates, reviews the sampling plan, and explicitly
starts a bounded 5–60 second check.

The implementation:

• opens one minimum-rights, non-inheritable Windows process handle and retains
  that same object without PID/name reopen or retarget;
• samples cumulative process CPU time on a monotonic schedule;
• preserves unavailable intervals and partial evidence;
• stops safely with CPU_PROCESS_EXIT_OBSERVED if the selected process exits;
• returns a bounded, privacy-allowlisted, IN_MEMORY_ONLY result;
• performs no process kill, suspension, restart, cleanup, remediation, elevation,
  priority change, affinity change, artifact persistence or automatic AI upload.

The first real live invocation exposed a PowerShell pwsh -File numeric
parameter-binding defect. That affected attempt failed with
CPU_CONFIGURATION_INVALID before Gate A, and no real target process was
acquired. The canonical no-coercion configuration validator behaved correctly
by rejecting string-typed numeric values; neither the CPU contract nor the
Windows adapter was wrong.

The fix was confined to the live CLI boundary. ProcessId and
DurationSeconds now cross the real -File binding boundary as validated
integer types before canonical configuration construction. Regression coverage
launches a genuine child pwsh -NoProfile -File ... against the production live
entrypoint. Valid integer CLI input reaches Gate A and cancels before acquisition;
fractional or otherwise invalid CLI input is rejected before Gate A. The
canonical no-coercion contract remains unchanged.

Validation

Runtime implementation baseline:
ef450c2679e38eb380278861adc66e4c9ab0c50e.

• Hosted Windows offline suite: 1859/1859 PASS, with zero failed, skipped,
  inconclusive or not-run tests.
• L1: normal 5-second live run; COMPLETED / CPU_WINDOW_COMPLETE; 6 attempted
  readings, 5 valid intervals and ALL_INTERVALS.
• L2: maximum 60-second live run; COMPLETED / CPU_WINDOW_COMPLETE; 61 attempted
  readings, 60 valid intervals and ALL_INTERVALS; no read 62.
• L3: 60-second configured live run in which the human manually closed the benign
  selected process; STOPPED / CPU_PROCESS_EXIT_OBSERVED; 8 attempted readings,
  7 valid intervals, 1 unavailable interval, 52 not-attempted intervals and
  SOME_INTERVALS; prior evidence was retained and the future schedule ceased
  after the terminal latch.
• L4: NOT_EXPOSED by design; no normal running cancellation path is claimed.
• Live environment observed: Windows with PowerShell 7.6.6. This is not a
  universal Windows/PowerShell compatibility guarantee.

These live runs validate behavior; they are not performance benchmarks.

Limitations

• Maturity remains EXPERIMENTAL; maintenance remains ACTIVE_BEST_EFFORT;
  not production-ready and no SLA.
• One manually selected process only; the human supplies the PID, with no
  automatic target discovery or selection.
• CPU evidence does not prove root cause, Codex ownership, task cost, a memory
  leak, residue/orphan state, or problem resolution.
• The metric is one-core-relative CPU time, not host CPU %, Task Manager process
  %, or logical-core-normalized utilization.
• No child-process or whole-application aggregation.
• No process control, cleanup, remediation or automatic retry/retarget.
• Results remain IN_MEMORY_ONLY; there is no persistent CPU artifact or
  automatic AI consumption.
• LIVE_CANCELLATION = NOT_EXPOSED; Ctrl+C is a hard interruption, not
  CPU_CANCELLED.
• Memory Trend is not implemented; T18.2B remains separate future work.
• Executable vectors are 22/22 positive and 37/38 negative. N30 remains
  PARTIAL because there is NO_EXISTING_T18_1_RUNTIME_SEAM; do not claim
  38/38 closure.

Operator documentation

Use the CPU Activity Check guide for the exact
PowerShell 7 invocation, gate tokens, metric interpretation, safety boundaries
and sanitized live-validation summary. The
demo storyboard prepares a future
recording but is not a capture or release asset.

The published v0.2.0-beta.1 remains an immutable historical prerelease with its
original target and capability claims. This release does not alter beta.1 facts or imply stable/production support.

Codex Resource Audit v0.2.0-beta.1 — Community Beta

Codex Resource Audit v0.2.0-beta.1

Community Beta prerelease for the current Windows-first, read-only CRA workflow.

Status

• Product maturity: EXPERIMENTAL.
• Release: COMMUNITY BETA / PRERELEASE; not production-ready.
• Maintenance: ACTIVE — BEST EFFORT. No SLA or guaranteed response/fix time.
• Independent open-source project; not an OpenAI product and not officially supported or endorsed by OpenAI.

What's included

• AI-assisted Incident Observation through the canonical cra-incident Skill, with an operator-run local PowerShell workflow.
• Human-owned candidate review, single-target selection and explicit O/OBSERVE, followed by human O1 and ACTIVITY_END timing gates.
• Bounded O0–O3 observation evidence. Only an O0 MATCHED identity check admits later captures; incomplete, stopped, cancelled and unknown outcomes remain explicit.
• Safe local candidate/review/final artifacts and context-validated interpretation. Artifacts are data, not AI execution permissions; CRA does not automatically upload them.
• Manual Guided Finder, Session and Observation where documented and eligible. The AI-assisted path supports Incident Observation only; Finder and Session are not AI-callable.
• First-run/troubleshooting guidance, evidence limits and possible next read-only investigation directions, plus support, security, contribution and compatibility policies and Issue Forms.

Important boundaries

NEWLY_OBSERVED != created by Codex/task
NO_LONGER_OBSERVED != process exit
PRESENT at O3 != residue / orphan / leak
working set != task cost / memory leak
parent-child != ownership
COMPLETED != bug confirmed / problem solved
Incident ownership = UNKNOWN
Incident lifecycle = NOT_APPLICABLE
UNKNOWN != CODEX

Snapshots do not describe everything between captures. Same PID alone is not exact identity. Codex can explain safe evidence but cannot select targets, confirm for the operator, drive the live terminal or enter timing gates. No automatic process cleanup or root-cause diagnosis is provided. CRA not uploading artifacts does not mean Codex processing is offline or all data stays on the machine.

Requirements

• Windows for live collection, in the operator's own interactive PowerShell 7 ConsoleHost, outside Codex's execution environment.
• Git for the clone example below.
• For AI-assisted use: local Codex on the same Windows machine, recognition of cra-incident, and the Skill, bridge and runtime from this same checkout.
• For the bridge: an existing parent directory on a local Windows drive and a new, nonexistent per-request output directory.

See Compatibility for requirements, validated/unverified scope and unknown environment details. Pester 6.2.0 is a development-test prerequisite, not a live-use prerequisite. There is no universal Windows/PowerShell/Codex-version acceptance claim.

Getting started

Select this fixed beta checkout:

git clone --branch v0.2.0-beta.1 https://github.com/Robinlee0929/codex-resource-audit.git
cd codex-resource-audit

Then follow README Quick Start for Skill preparation and the operator-owned workflow, using this checkout throughout. Consult First-run and troubleshooting when setup or observation is blocked. The versioned documentation records the pre-release preparation state; this release identifies the verified beta tag and commit.

Feedback and support

Use GitHub Issues and Issue Forms for normal bugs, questions, ideas and feedback. Read Support / minimum disclosure and Contributing.

Report suspected vulnerabilities through GitHub Private Vulnerability Reporting, following Security reporting, rather than a public Issue or PR.

Share only version/commit, relevant environment versions (or unknown), workflow/stage, fixed reason code if available, sanitized reproduction steps, and expected versus actual behavior. Do not attach logs, screenshots or artifacts by default. Never publish credentials, command lines, private paths, real PIDs, full process tables, raw dumps or terminal transcripts. Additional data requires prior agreement on the minimum necessary field and appropriate channel.

Validation

Release target: dd865498af7ae0c6aef79338df1c642b63ec5a5b.

Hosted Windows offline tests — run 35300788069 ran against this exact commit:

Executed: 1384
Passed: 1384
Failed: 0
Skipped: 0
NotRun: 0
Inconclusive: 0

This is synthetic/offline test validation, not universal live-host/client acceptance, a production-readiness guarantee or a new live-validation claim. Historical acceptance records retain their own scope and unknown fields.

Not included yet

T18 follow-up diagnostic runtime, including automatic triage, CPU Activity and Memory Trend collectors, and automatic diagnostic execution, is not included in this beta runtime. T18.0 / T18.1 / T18.2A specification files are design contracts, not implemented runtime capabilities.

There is no autonomous target selection, AI operator confirmation, automatic cleanup, root-cause diagnosis or definitive residue/leak detection. This release does not replace or reinterpret the historical v0.1.0 / v0.1.1 releases. No beta-specific release assets are attached.

Codex Resource Audit v0.1.1

Codex Resource Audit v0.1.1

Guided operator workflow and issue-evidence improvements for the Windows-first, read-only Codex process attribution tool.

Highlights

• Guided interactive discovery, candidate review, single-target selection, explicit VERIFY, and exact root identity revalidation.
• Clear S0 baseline → activity → S1 → TASK_END → S2/S3/S4 observation workflow.
• Summary-first results with canonical DETAILS on demand.
• Task Delta distinguishes confirmed task-window identities from pre-existing observations.
• Validated zero results remain distinct from UNAVAILABLE evidence.
• Process Branch Origin explains how task-window processes group into confirmed process branches.
• Bounded NEXT STEP guidance without changing evidence classification.
• Improved terminal readability, compact candidate presentation, and NO_COLOR support.
• Guided Quick Start and privacy-sanitized v0.1.1 replay demo.

Validation

Release commit:

f27b509b406e9c975e614ce11602fb2c74dd5f6b

Hosted Windows offline tests:

PASS

GitHub Actions run:

34800042483

The hosted workflow ran on the exact commit referenced by v0.1.1.

Local T9 validation:

• Pester 6.2.0
• 629 / 629 PASS
• 0 failed
• 0 skipped
• 0 inconclusive
• 0 NotRun
• 45 / 45 tracked PowerShell files parse successfully
• Privacy review PASS
• Claim-boundary review PASS
• Final demo acceptance PASS

Previously accepted external controls:

• Negative control: AVAILABLE Task Delta with 0 created identities and AVAILABLE Branch Origin with 0 branches.
• Positive control: 4 confirmed task-window processes → 1 process branch; all were NO_LONGER_OBSERVED by S4.

NO_LONGER_OBSERVED != EXIT_CONFIRMED

The demo is a privacy-sanitized replay, not another live validation run.

Demo

SANITIZED REPLAY · NOT A LIVE CAPTURE

Accepted demo:

• 1280×720
• 25 fps
• 43.96 seconds
• 1099 / 1099 readable frames
• Final technical review PASS
• Final ten-frame visual review PASS

Positive-control story:

4 confirmed task-window processes → 1 process branch

A process branch does not establish a logical session or tool-call causation.

Safety boundaries

UNKNOWN != CODEX
TASK_END != PROCESS_EXIT
FIRST_SEEN != CREATION_TIME
TASK_WINDOW_TIMING != TASK_CAUSATION
PRE_EXISTING_AT_S0 != TASK_CREATED
NO_LONGER_OBSERVED != EXIT_CONFIRMED
STILL_OBSERVED != RESIDUE
PROCESS_BRANCH != LOGICAL_SESSION
PROCESS_PARENTAGE != TOOL_CAUSATION
NEXT_STEP_GUIDANCE != EVIDENCE_CLASSIFICATION

Codex Resource Audit v0.1.0

Codex Resource Audit v0.1.0

First public release of Codex Resource Audit — a Windows-first, read-only evidence tool for attributing Codex-owned processes and explaining lifecycle observations without unsafe assumptions.

Observe → Verify → Attribute → Explain → Compare

What it helps you do

A typical workflow is:

1. Discover possible Codex root candidates.
2. Independently verify one current root using PID + creation time + executable path.
3. Capture the task across S0–S4.
4. Compare what appeared, changed, or was no longer observed.
5. Attribute processes only when ownership evidence is sufficient.
6. Review lifecycle evidence separately.

The core principle is:

See what changed. Claim only what the evidence supports.

Highlights

• Candidate discovery with neutral grouping and Quick Index
• Explicit operator-verified root workflow
• Exact process identity using PID + creation time + executable path
• Fail-closed Codex ownership attribution
• S0–S4 foreground Session capture
• Concise Evidence Summary
• Lifecycle UNKNOWN explanations
• Synthetic/offline examples for safe evaluation
• Windows GitHub Actions offline CI

Safety boundaries

UNKNOWN != CODEX
CANDIDATE_ONLY != VERIFIED_ROOT
ATTACHED_BROWSER != CODEX_OWNED
PROCESS_SURVIVAL != RESIDUE
PROCESS_SURVIVAL != ORPHAN
PARENT_NOT_OBSERVED != EXIT_CONFIRMED
NO_LONGER_OBSERVED != EXIT_CONFIRMED