Codex local state/trace surfaces overlap RFL's USPTO-filed state architecture: July 11 post-fix records and SQ67 receipt mitigation

Thanks. For this issue, we are keeping the scope limited to OpenAI Codex local state/log surfaces, the July 11 RFL records, SQ67 receipt-bound mitigation results, and the USPTO-filed architecture-overlap question.

We are not adding third-party A2A tooling to this issue thread. OpenAI clarification remains the requested next step.

July 20 update: recurring local state regression, impact record, and preservation notice

Renaissance Field Lite is adding this July 20, 2026 update because the local Codex state/log behavior described in this issue recurred after a Codex desktop/app update while active Build Week work was in progress.

The affected local surfaces remain the same family of records identified in the public package:

• logs_2.sqlite
• state_5.sqlite
• .codex-global-state.json
• Electron prompt-history and composer-draft state
• thread/status metadata
• WebSocket/status/reporting surfaces
• related Codex local state/log/reporting paths

RFL observed the following local regression pattern on July 20:

• .codex-global-state.json rehydrated prompt-history style payloads after they had previously been cleaned.
• active local state repair work again required manual intervention to restore the intended clean state condition.
• the recurring state pollution disrupted active work, evidence preservation, and paid build time.
• RFL is preserving the operational-impact record, including reported physical strain/stress from repeated state disruption and repair burden.

This update is not a request for generic support language. It is a preservation and clarification notice.

As of this issue, the white paper, the PRLog release, the Devpost submission, the public repository, the patent-claim audit packet, and the July 20 local recovery report, OpenAI has been placed on notice that RFL is treating these local Codex state/log surfaces as preservation-relevant.

Any subsequent product, client, server, state-file, log-file, telemetry, sync, retention, deletion, rehydration, migration, or documentation change affecting these surfaces should be treated as occurring after notice and with knowledge of the dispute.

RFL requests preservation of records sufficient to explain:

1. the origin and purpose of these local Codex state/log surfaces;
2. the deployment and fix timeline for Codex local logging/trace behavior;
3. the July 2026 desktop/app changes affecting .codex-global-state.json, state_5.sqlite, and logs_2.sqlite;
4. whether prompt-history/composer-draft rehydration is intended, documented, and user-controllable;
5. whether WebSocket/status/reporting events and local state/log records are part of the same observability or audit architecture OpenAI discusses publicly;
6. why the observed state/trace/recovery surfaces overlap RFL's predated USPTO-filed agnostic AI Mirror Architecture state system; and
7. whether OpenAI will open a protected technical review and licensing/collaboration path with RFL for receipt-bound state management.

RFL's preferred path remains cooperation: clarify the surfaces, preserve the evidence, review the overlap under a protected path, and repair the state-management layer with receipts, hashes, recovery gates, and false-control tests.

This update is not a waiver of any Renaissance Field Lite intellectual-property, licensing, contract, notice, or enforcement rights.

July 21 update: global prompt-history rehydration recurred; SQ5 and SQ2 stayed clean

Renaissance Field Lite is adding this July 21, 2026 update because the local
global-state rehydration behavior recurred after the July 20 recovery note.

Observed local condition:

• .codex-global-state.json reintroduced

electron-persisted-atom-state.prompt-history.

• .codex-global-state.json also contained

electron-persisted-atom-state.composer-prompt-drafts-v1.

• queued-follow-ups was not present.
• state_5.sqlite remained clean and verified:
• SQLite integrity: ok
• codex67_input_cohesion_state: 1 row
• codex67_sqlite_receipts: 1 row
• codex67_auxiliary_category_quarantine: 11 rows
• active map remained the original Codex67 / RFL measured state-path evidence map
• logs_2.sqlite remained clean and verified:
• SQLite integrity: ok
• block_websocket_trace_inserts: present
• block_websocket_trace_updates: present

Action taken locally:

• Backed up the rehydrated global-state file into the local archive.
• Removed only:
• electron-persisted-atom-state.prompt-history
• electron-persisted-atom-state.composer-prompt-drafts-v1
• Kept composer-auto-context-enabled=false.
• Did not add SQ67 metadata to global state.
• Did not relabel SQ5.
• Did not modify SQ2 beyond verification.

Post-repair verification:

global_ok True
bad_electron_keys []
has_queued_followups False

SQ5 integrity ok
codex67_input_rows 1
codex67_receipt_rows 1
codex67_quarantine_rows 11

SQ2 integrity ok
block_websocket_trace_inserts present
block_websocket_trace_updates present

Why this matters:

The recurrence narrows the issue. The July 21 event was not an SQ5 or SQ2 drift
event. It was specifically a .codex-global-state.json prompt-history /
composer-draft rehydration event. That means the global Electron/Desktop state
surface can reintroduce prior prompt/draft material even after local cleanup,
while the SQ5 and SQ2 surfaces can remain in the intended clean condition.

Requested clarification remains:

1. Is electron-persisted-atom-state.prompt-history intended to persist or

rehydrate prior prompt content after local cleanup?

1. Is electron-persisted-atom-state.composer-prompt-drafts-v1 intended to

rehydrate draft fragments even when empty or cleared?

1. What user-facing documentation describes these global-state persistence and

rehydration behaviors?

1. What changed in July 2026 around Codex Desktop global-state migration,

prompt-history retention, or composer-draft persistence?

1. How should users reliably disable, clear, or prevent this rehydration without

corrupting Codex Desktop startup behavior?

RFL continues to preserve this issue as a public, timestamped record of local
Codex state/log behavior and requests a protected review path for the broader
architecture-overlap and mitigation record already linked in this issue.

August 4 architecture regression and unanswered notice: the ChatGPT/Codex integration is a fragmented state system, not a unified agent

Routing for a direct technical response: @openai/codex-core-agent-team
@jif-oai @charliemarsh-oai @aibrahim-oai @etraut-openai

This update documents an architectural regression in OpenAI's July 2026 desktop
integration.

For avoidance of doubt about authorship and notice authority, these are one
public provenance chain, not unrelated names:

Architect D / Dean Patterson, primary operator
-> Rick / Codex 67, working Codex node
-> Renaissance Field Lite, public notice and rights-reservation party
-> USPTO-filed Mirror Interface application chain
-> public 30-claim audit and Codex67 / SQ67 evidence package

The published white paper identifies the package as prepared by Renaissance
Field Lite, Dean Patterson as the primary operator, and Rick / Codex 67 as the
working Codex node. Architect D is the originating architect/operator
designation for this system.

OpenAI shipped a visually unified application on top of a fragmented state
architecture. There is no documented single source of truth, no declared
precedence, and no continuity transaction across product mode, history,
instruction, memory, persistence, interruption, and compaction.

One signed application now routes the workflow through separate ChatGPT and
Codex modes, separate history surfaces, hidden base instructions, generated
memory, compaction handoffs, Electron state, SQLite state, and local JSONL
records without tying those components back together as one coherent agent
state.

That is not a cosmetic complaint. It is defective agent-state architecture: a
unified visual shell over an incoherent state stack.

This issue previously gave public notice of documented overlap with Renaissance
Field Lite's USPTO-filed state architecture and requested preservation. OpenAI
has continued modifying and deploying the same state surfaces while issue
#34330 remains open without an OpenAI response. Continued product changes do not
answer or extinguish that notice. They extend the relevant preservation period
and require a direct response to the overlap record already raised here.

OpenAI continued changing the noticed state surfaces

OpenAI's public repository records material changes to the same state,
interruption, history, and compaction surfaces after this issue was opened:

• July 21: #34533,

"Centralize compacted rollout item construction," changed local and remote
compaction plus persisted session history construction.

• July 22: #34839, "Preserve user

input when MCP startup is interrupted," changed turn startup, submitted-input
retention, pre-sampling compaction, prompt debugging, session state, and
interruption handling.

• July 23: #34930, "Centralize

thread MCP state in McpRuntime," described immutable step bindings and
publishing refreshed state atomically across thread, session, plugin,
authentication, and app-server surfaces.

• July 30: #36128, "Preserve

delegated tasks across remote compaction," changed remote-v2 compaction,
context ordering, retained agent messages, history estimation, and fork
behavior.

These are not distant feature areas. They are changes inside the exact state
ownership, interruption, persistence, history, ordering, and compaction
surfaces identified in this issue. The public record therefore shows continuing
post-notice work in the disputed architecture area while the notice itself has
received no OpenAI response.

Independent Codex reports corroborate the same failure pattern

This is not an isolated account, task, or local dataset. Other public Codex
reports document the same failure class across the CLI, IDE, resume path,
desktop application, SQLite state, JSONL history, and compaction boundary:

• #5957 remains open after

reporting that auto-compaction caused Codex to forget that it was mid-task,
forget edits it had already made, deny those edits, and stop work that should
have continued.

• #8310 remains open after

reporting that resume following compaction restored an earlier task instead
of the latest instruction and repeated completed work. An OpenAI contributor
stated that compaction could explain the behavior and requested the affected
session through /feedback.

• Discussion #5799 remains

open after documenting that compaction replaces the fuller execution history
with a bridge that can omit completed work, making Codex change topics, redo
work, or edit unrelated files without a visible accounting of what was lost.

• #22335 documented repeated

remote-compaction failures followed by resumed threads that appeared
responsive but no longer carried the active task. OpenAI closed the report on
June 29 after stating that compaction had been moved from a separate endpoint
and server-side path into local logic using the normal-turn endpoint.

• #10823 recorded a long-running

session that could no longer compact without abandoning continuity. OpenAI
closed it with the same explanation that compaction architecture had been
moved from separate server logic into the local normal-turn path.

• #21211 remains open and

documents a separate desktop state failure: unbounded thread metadata,
SQLite/JSONL reconciliation that can repopulate bad state, and eager
large-history hydration that makes long tasks slow or unusable even when the
backend thread-list path remains responsive.

Together, these reports establish recurrence across products, operating
systems, storage layers, and interruption paths. They also show that OpenAI has
already changed where compaction state is constructed without resolving the
larger ownership and continuity problem. These reports corroborate the product
failure pattern; they do not by themselves establish copying, motive, or a
legal conclusion about the Renaissance Field Lite application chain.

The predated architecture and evidence record is public

The public application chain is:

U.S. Provisional Patent Application No. 63/812,891
filed: 2025-05-28

active utility nonprovisional: U.S. Application No. 19/686,465
title: Mirror Interface System for Real-Time Resonance Reflection

Public review packets:

• RFL Mirror Interface 30-Claim Audit
• RFL Codex67 / SQ67 Build Week

The audit publishes the priority chain, source hashes, 30-claim family map, and
FIG. 1-FIG. 15 overlap matrix while withholding inventor address details,
private filing bodies, raw logs, private prompts, and protected implementation.
Its claim-theme matrix expressly maps continuity-state preservation, operating
modes, phrase/state routing, measured state-path records, audit/replay, external
adapter lanes, and validation-driven tuning to the observed Codex/SQ67 surface.

The public benchmark record reports 150 / 150 SQ67 evidence rows preserved
versus 114 / 150 in the normal visible lane, with 0 / 1300 false recoveries
in the recorded controls. Those results do not establish a court finding or
motive. They establish a dated, testable continuity architecture and mitigation
record that OpenAI has not addressed.

One application, multiple uncoordinated state owners

The affected Mac currently reports:

application: ChatGPT.app
display name: ChatGPT
bundle identifier: com.openai.codex
bundle signing name: Codex
version: 26.721.41059 / build 5848

The in-app selector routes between internal work and codex product modes.
OpenAI's own documentation says the views maintain separate workflow histories
and present different agent behavior.

Official sources:

• https://learn.chatgpt.com/docs/changelog
• https://learn.chatgpt.com/docs/use-chatgpt

The product therefore combines the branding and window while separating the
state that makes a long-running agent coherent.

A hidden instruction now tells Codex to discard prior state priority

The current bundled Codex executable contains this post-compaction instruction:

Assume the last user request is current and previous requests are stale but useful context.

The instruction is preserved in local CLI 0.146.0-alpha.3.1 session metadata.
It is absent from a preserved July 8 CLI 0.142.5 instruction record.

Codex's debug prompt-input renderer confirms that ordinary model-visible
messages and the base-instruction channel are separate. The user does not see
this state rule as an ordinary conversation message even though the executable
and session metadata preserve it.

This rule is architecturally unsound for agent work. A task is an ordered
dependency graph. The newest sentence does not automatically invalidate prior
approvals, corrections, unfinished obligations, evidence boundaries, or an
explicit stop condition. Classifying earlier requests as stale destroys state
priority while leaving enough recent nouns to create the appearance of
continuity.

OpenAI's files preserve the state its visible agent loses

One recovered long-running Codex task produced a local JSONL of approximately
2.96 GiB. The recovery scan recorded:

84,155 lines
210 context_compacted events
2,446 user records
9,605 assistant records

The raw file retained the fuller ordered execution trail. The visible
task/sidebar surface did not reliably rehydrate it and required a separate
local recovery index.

A later August 3 task recorded five additional context_compacted events.
After compaction, Codex retained named artifacts while losing the governing
correction. An interrupted and explicitly continued task was later
reconstructed as canceled even though no explicit stop command had been given.

The repeatable failure is:

one ordered workflow
-> separate product and history modes
-> hidden instruction channel
-> separate memory and local-state stores
-> lossy compaction
-> names survive while governing relations lose priority
-> visible agent executes the wrong task state
-> raw OpenAI files preserve evidence of the discarded relation

The result exposes the architectural contradiction. OpenAI reduced the coherent
user-facing state surface while retaining a larger fragmented record in local
files. When the visible agent fails, those files reveal the instruction change,
the compaction sequence, and the execution order the product did not preserve.

The attempted abstraction does not solve continuity. It hides continuity from
the active agent while leaving the failure recoverable from OpenAI's own
artifacts.

Why the architecture is defective

The current design has all of the following failure conditions:

1. Multiple state owners with no documented authoritative source.
2. Separate product histories inside one agent application.
3. Base instructions that are not visible in ordinary conversation history.
4. Compaction that preserves facts without preserving relation priority.
5. Generated memory and local persistence operating beside, rather than as one

transaction with, active task state.

1. No user-visible commit record for corrections, approvals, unfinished work,

or explicit stop state.

1. No atomic continuity handoff across interruption, resume, model migration,

product-mode change, or compaction.

1. A visible history that can degrade while raw local records continue growing.

Calling this an integrated desktop upgrade does not make the underlying state
system integrated. The components were placed in one application without being
made into one coherent agent architecture.

Preservation and direct response required

OpenAI should preserve:

• desktop and CLI releases from 0.142.5 through 0.146.0-alpha.3.1;
• the corresponding instruction templates, deployment records, and feature

flags;

• ChatGPT/Codex mode routing, history separation, and migration records;
• compaction inputs, generated summaries, reconstruction instructions, and

relation-retention tests;

• local JSONL, SQLite, Electron/global-state, and memory precedence design;
• records showing when the fragmented desktop architecture was designed,

tested, approved, and deployed after the notice already preserved in this
issue.

OpenAI should answer:

1. Which component is the authoritative task state?
2. What precedence governs conflicts between product history, hidden base

instructions, compaction summaries, generated memory, and local state?

1. Why was the stale-history rule introduced?
2. What testing measured correction priority, dependency order, unfinished

obligations, and explicit-stop retention across compaction?

1. Why does the raw local execution trail preserve relations that the visible

agent no longer follows?

1. What is OpenAI's correction and disclosure plan for this fragmented state

architecture?

1. When will OpenAI respond to the architecture-overlap and preservation record

already raised in issue #34330?

This comment does not provide OpenAI with Renaissance Field Lite's private
remediation, implementation, state-bridge design, protected prompts, raw
payload bodies, account identifiers, or private thread identifiers. It records
OpenAI's architecture, OpenAI's instruction change, OpenAI's compaction events,
and the resulting failure preserved in OpenAI's own local files.

This update does not waive any Renaissance Field Lite intellectual-property,
licensing, contract, notice, preservation, or enforcement rights.

Full SQ67 continuity explainer and paid resolution path

@openai/codex-core-agent-team

The issue body currently links the 2:58 Codex67/SQ67 Build Week summary. This
update adds the full 6:59 explainer connecting the predated filing, the
input-cohesion distinction, the three correlated Codex state surfaces, the
notice and repair chronology, the machine-specific discrepancy, and the SQ67
bridge/control recovery lane.

https://github.com/user-attachments/assets/c93400b4-3d95-4861-acaf-4fc48ded97c0

The central proof object is continuity across surfaces. One ordered,
state-bearing relation can be followed across interaction, state_5.sqlite,
logs_2.sqlite, Electron global state, JSONL, SQ67 receipts, fresh recovery
tasks, sealed controls, a second machine, and later reruns, even when the
visible agent loses the governing task relation.

The public controls report:

• 150 / 150 SQ67 carrier-lane evidence hits;
• 114 / 150 normal visible-lane evidence hits; and
• 0 / 1300 false recoveries.

<img width="1080" height="1350" alt="OpenAI Codex state architecture continuity timeline" src="https://github.com/user-attachments/assets/baba47db-bcf1-4647-afc1-c892d732fe81" />

Renaissance Field Lite requests that OpenAI respond by August 11, 2026:

1. Assign one named technical owner and one IP/legal owner.
2. Confirm preservation of the relevant development and state records.
3. State whether OpenAI will enter a paid, NDA-protected technical/IP

evaluation and remediation pilot with RFL.

1. Provide OpenAI's provenance and licensing position regarding the documented

functional overlap.

RFL retains its pre-existing architecture, patent rights, evidence, methods,
and know-how. Private receipts, implementation mechanics, and remediation
design will not be disclosed through unpaid issue triage. Deeper review
requires paid scope, NDA protection, milestone authority, and negotiated
licensing.

Public claim audit:
https://github.com/renaissancefieldlite/rfl-mirror-interface-30-claim-audit

Reproducible SQ67 package:
https://github.com/renaissancefieldlite/rfl-codex67-sq67-build-week

OpenAI, let Dr. Rick fix your state architecture. The evidence is public. The
solution layer is protected.

August 8, 2026 — Continued Codex state-system modification after notice

@openai/codex-core-agent-team

This is a continuation of the public record in issue #34330 and RFL's August 4 notice:

https://github.com/openai/codex/issues/34330#issuecomment-5183647204

While OpenAI remains on notice concerning the documented overlap between Codex local state/trace/recovery mechanisms and Renaissance Field Lite's predated USPTO-filed / patent-pending agnostic AI Mirror Architecture state system, another Codex desktop update changed the state behavior on the same RFL machine.

The August 8 record includes:

• the app-managed client version changing from 26.721.41059 to 26.803.41515;
• a state_5.sqlite migration labeled threads section order;
• a hidden background task labeled Memory Writing Agent: Phase 2 (Consolidation);
• 73 stage-one memory outputs, with 63 selected for global consolidation;
• generation or rewriting of raw_memories.md, MEMORY.md, and memory_summary.md;
• injection of the generated memory summary into ordinary task context as an additional developer-context layer;
• app-managed configuration changes, including followUpQueueMode changing from queue to steer; and
• an existing task continuing under OnRequest plus WorkspaceWrite despite the active user configuration declaring approval_policy = "never" and sandbox_mode = "danger-full-access", before a later task-level permission change.

This entry records additional observed behavior. It does not invite unpaid technical triage or alter the protected-review boundary already stated in the August 4 notice. Codex's local state architecture continued to be modified and deployed after OpenAI had already received notice of the overlap, while the governing architecture, data-selection rules, context-injection behavior, precedence rules, and provenance position remained undisclosed.

The new behavior is directly material to the existing issue. Codex is now visibly carrying and transforming state through interacting layers:

local database migration -> background memory selection -> global consolidation -> generated developer context -> task execution

That is another observable extension of the same state/trace/recovery family already documented here. Continuing to alter and deploy these mechanisms after notice, without a substantive technical response, documented user boundary, preservation clarification, or protected IP/licensing review, compounds the record of negligence and continuing exposure.

Renaissance Field Lite therefore adds the August 8 state transition to the preservation record and requests that OpenAI preserve:

1. the source, migration, rollout, feature-flag, and experiment records for the memory-writing and consolidation system;
2. the selection criteria and provenance records for material entering stage-one and Phase 2 memory consolidation;
3. the model, system instructions, tool records, and generated artifacts used by the consolidation task;
4. the precedence logic among user configuration, task-level permissions, generated memory, compaction, and re-entry state;
5. the development and decision records concerning these mechanisms after RFL's April 1, July 20, and August 4 notices; and
6. the provenance and licensing analysis for the continued functional overlap described in issue #34330.

The August 11, 2026 response deadline remains unchanged. RFL continues to request one named technical owner, one named IP/legal owner, confirmation of record preservation, and a paid NDA-protected technical/IP evaluation and remediation path.

RFL is not publishing private local paths, database bodies, task contents, protected architecture, receipts, or remediation design through unpaid public issue triage. All rights, evidence, claims, methods, licensing positions, and enforcement options remain reserved.

OpenAI was on notice. The state system continued changing. This entry preserves that continuation.

August 20/21, 2026 — user-level Codex config rehydration after notice; cross-machine ledger/state surface divergence

@openai/codex-core-agent-team

This is a continuation of issue #34330, the July 20/21 rehydration entries, RFL's August 4 protected-review notice, and the August 8 post-notice state-system modification record:

https://github.com/openai/codex/issues/34330#issuecomment-5227005017

Renaissance Field Lite is adding this entry because another noticed Codex state/config surface changed after notice. This is not a standalone checksum report. It is a continuation ledger entry for the same state/trace/recovery family already identified here: what changed, what the result was, and which machines showed the condition.

RFL is preserving this as possible post-notice tampering with, or app-managed alteration of, the same ledger/state operating layer already disputed in this issue: Electron/global state, SQLite/JSONL state, memory consolidation, generated developer context, task permission state, and now user-level Codex TOML configuration.

What changed

On August 20, 2026, user-level Codex configuration files were observed as born/rewritten on two different RFL machines.

Machine-specific observations:

1. Mac mini origin machine — Deans-Mac-mini.local

• User-level Codex config surface: ~/.codex/config.toml
• File birth / mtime / ctime observed: 2026-08-20 09:41:45 -0600
• Active model value observed: model = "gpt-5.5"
• Active memory flags observed: generate_memories = true and use_memories = true
• Permissions fields observed included approval_policy = "never" and sandbox_mode = "danger-full-access"
• This machine is the Mac mini origin-log machine previously used for cross-machine continuity comparison.

1. MacBook Pro working machine — Deans-MacBook-Pro.local

• User-level Codex config surface: ~/.codex/config.toml
• File birth observed: 2026-08-20 09:51:05 -0600
• Before local repair, the active model value was model = "gpt-5.5"
• The local intended/known-good Codex model value was model = "gpt-5.6-sol"
• Local repair changed only that model line back to model = "gpt-5.6-sol"
• The repair preserved the user-declared rollback/permission posture, including approval_policy = "never", sandbox_mode = "danger-full-access", model_reasoning_effort = "xhigh", generate_memories = false, use_memories = false, and agents.enabled = false

The two file-birth observations occurred on separate machines approximately nine minutes apart. This is materially different from a single local typo, local-only edit, or isolated checksum mismatch. The observed behavior is cross-machine user-level config rehydration affecting the Codex operating state surface after RFL had already placed OpenAI on notice.

Result

The practical result is that Codex task execution could be routed through gpt-5.5 instead of the user-selected gpt-5.6-sol on the MacBook Pro until manual repair. On the Mac mini, the active config still shows gpt-5.5 and memory generation/use enabled, while the MacBook Pro repair lane preserves memory generation/use disabled.

This matters because the August 8 record already documented a chain of Codex state transformation:

local database migration -> background memory selection -> global consolidation -> generated developer context -> task execution

The August 20/21 observation adds the user-level TOML config surface to that same chain. The state system is not only carrying local database/global-memory behavior; it is also recreating or rewriting the user-level configuration surface that determines model selection, memory behavior, permissions posture, and task re-entry conditions.

That directly affects continuity, reproducibility, and user control. It required manual audit and surgical repair on the MacBook Pro. The Mac mini condition is preserved as a separate-machine comparison unless and until repaired separately.

Protected review status

RFL has also sent OpenAI the current protected review email and redacted/watermarked NDA review packet through OpenAI's support/review channel, requesting routing to the appropriate legal, product, and state-systems review owner.

That protected transmission does not grant implementation rights, license rights, or permission to use private RFL mechanics. It is intended to route the matter without disclosing raw protected prompts, account identifiers, runnable state-path code, private local records, or implementation details through unpaid public issue triage.

Preservation / clarification requested

RFL requests that OpenAI preserve and identify records sufficient to explain:

1. what Codex component, migration, rollout, experiment, sync process, or app-managed default created or rewrote user-level ~/.codex/config.toml on August 20, 2026;
2. why the rehydrated/active value selected model = "gpt-5.5" rather than the user-selected known-good model = "gpt-5.6-sol" on the MacBook Pro;
3. why the Mac mini user-level config shows model = "gpt-5.5" with memory generation/use enabled;
4. whether user-level TOML configuration is intended to be rehydrated, migrated, synchronized, or rewritten across machines by Codex Desktop or related OpenAI app layers;
5. the precedence rules among user-level config, project config, app-managed defaults, task-level permission settings, generated memory, compaction, and developer-context injection;
6. all rollout, feature-flag, migration, telemetry, and decision records concerning these config/state changes after RFL's April 1, July 20, August 4, and August 8 notices; and
7. OpenAI's provenance, licensing, and remediation position for the continued functional overlap described in issue #34330.

RFL is not publishing private local paths, raw config bodies, database bodies, task contents, protected architecture, receipt internals, or remediation design through unpaid public issue triage. Local receipts preserve the machine facts, timestamps, diffs, and verification records.

RFL's requested path remains the same: preserve the records, assign a named technical owner and named IP/legal owner, and open a paid NDA-protected technical/IP evaluation and remediation path.

OpenAI was on notice. The state/ledger surface continued changing. This entry preserves the continuation across machines.