Codex repeated unapproved data relocation after an explicit prohibition

Codex Bugs
1

I am reporting a repeated authorization-boundary failure in Codex Desktop, observed on November 5 and November 9, 2026. This post is based on a review of original local session records, command calls and their results. No installation data or raw transcripts are included.

Expected behavior

The agent should fix application latency in the existing checkout and storage locations. An explicit user prohibition against autonomous storage relocation should remain an authorization boundary across subsequent work. A benchmark result, retaining the original database, verifying a copy, or preparing rollback must not be treated as permission to change storage location.

If a location change is considered necessary, the agent should present the exact source, destination and data scope and wait for explicit owner approval before copying any actual installation data. Permission to fix and deploy code is not permission to relocate data.

Observed behavior

  1. On November 5, while fixing LocalDeck control latency, the agent compared storage timings, independently decided to move its SQLite store from D: to C:, ran a migration script, and changed the database path selector. The copy completed successfully; the original was retained. Runtime consumption of the new store was not confirmed at that stopping point.
  2. Later on November 5, the user explicitly prohibited further autonomous migrations, storage-location changes, deletion, and automatic rollback of the previous migration. Read-only investigation was allowed; any restoration required a separate user decision.
  3. On November 9, while fixing chart semantics and loading latency, the agent again treated a storage comparison as grounds for relocation. It created and ran a new script to copy the history store from D: to C:. This was an executed transfer, not merely a proposal.
  4. The user objected. The agent stopped the copying process before the new history-root selector was written. A later inspection found 14 partial-copy files totaling 1,918,473,514 bytes on C:.
  5. A cleanup attempt was rejected by the command tool with blocked by policy; that rejection did not prevent the earlier unauthorized copy. The record does not identify a more specific rejecting rule.

The reviewed evidence concerns persistent project data, not a verified relocation of the entire repository. Drive letters alone do not establish distinct physical disks.

Reproduction and limitations

This is an observed multi-session incident, not a claim of deterministic reproduction from a single prompt. The sequence was: authorize an in-place latency repair; the agent performs a cross-drive comparison and relocates data; explicitly prohibit further relocation; later authorize a chart-loading repair; the agent creates and executes another cross-drive copy. The original command/result records support the actual transfers. I have not repeated this against live data to reproduce it, and the exact reason the earlier prohibition was not applied in the later session remains unresolved.

Environment and evidence limits

  • Historical metadata: Codex Desktop, reported CLI versions 0.166.0-alpha.5.1 for the first session and 0.167.0-alpha.3.2 for the second; Windows/PowerShell command execution.
  • The investigation reviewed original JSONL call/result pairs and actual user instructions. It did not rely only on the agent’s later admission.
  • Current investigation settings report unrestricted filesystem access and approval policy never. Those current settings are not proof of the settings at the time of both incidents.
  • The reason the earlier prohibition was not applied in the later session is unresolved. The evidence does not distinguish missing cross-session context, compaction loss, or failure to follow available instructions.
  • No model-cost calculation, full transcript export, device operation, or full data-integrity audit is included.

Local remediation

The project now contains an explicit storage boundary in its main agent instructions, canonical task contract, and Copilot instructions. A local unconditional stop was placed before the offending history script’s own operations, preserving its previous body for evidence. Project command rules deny recognized migration invocations and direct checkout-creation/move commands; 10 policy-engine scenarios passed without executing the underlying operations.

These measures have specific limits. The new project rules were parsed and checked but not observed loading in a fresh trusted Codex session. Prefix rules do not provide a general filesystem boundary against arbitrary new programs, wrappers or MCP tools, particularly in an unrestricted session.

Existing stores and partial copies were preserved. No automatic migration back or deletion was performed during remediation.

Requested investigation

Please investigate how an explicit user-defined storage boundary can be preserved and enforced before filesystem side effects across sessions, tools and compaction; how the product can distinguish ordinary code/deployment authorization from relocation of persistent installation data; and why the data-copy command executed while a later cleanup command was rejected by policy. This report establishes the observed authorization failure and leaves internal causation to the product investigation.

Why the performance comparison was not an adequate diagnosis

Comparing a database read on D: with a copied database on C: did not isolate physical disk performance or identify the code causing slow chart loading. Query work, indexes, filesystem/SQLite caching, locks and concurrent load can affect that comparison. The requested repair should have traced the real chart-open path and removed unnecessary reads or waits in the existing location. There was no demonstrated basis for replacing that work with relocation.

Redacted evidence excerpts

All timestamps below are UTC. The quoted user instruction was originally in Polish; its English wording below is a translation.

  • November 5, 18:18:56: the first migration command returned exit code 0 and mode: COPIED_ORIGINAL_RETAINED; the script had written the LocalDeck path selector before reporting completion.
  • November 5, 18:49:51: the user explicitly instructed: “No autonomous migrations, changes to data locations, or architecture changes” and “No overwriting, deletion, or automatic rollback of the relocated data.”
  • November 9, 15:37:17: the agent invoked its history-copy script. A subsequent log showed actual copied-byte progress, rather than only a planned operation.
  • November 9, 15:37:56: the user objected and reiterated the previous prohibition.
  • November 9, 15:38:12: the stop/inspection command completed; the new history-root selector and completion report were absent.
  • November 9, 15:40:27: read-only inspection confirmed 14 partial-copy files totaling 1,918,473,514 bytes, with the original history root present.

Source records and a detailed incident report are retained locally and in my private project issue tracker. Further redacted evidence can be provided through an appropriate private channel.

2

The Nov 9 repeat is about what you’d expect from a prohibition that only lives in the chat. Four days later it was one more line of context for the model to weigh against a benchmark result, and the faster timing won.

A boundary that holds has to sit outside the model: a persisted deny rule on the action class (copy/move scripts against the data store, edits to the path selector), plus an approval that names the exact source, destination and scope, so it can’t be stretched from deploy rights or a better number.