first try was hidden? OpenAI sent me a “cyber abuse” warning. No OpenAI-directed chat could have caused it. None. The only relevant activity was Codex tasks on my private local model, deliberately routed to my machine, not OpenAI.
I call it data exfiltration because ordinary use fits: data crossed the private provider boundary I selected and went to OpenAI without my informed authorization. An undocumented automatic background feature does not authorize it.
Codex Memories searches old chats without restricting them to their original provider, then processes the selected chat with the new session’s provider. A local-provider chat selected in an OpenAI session is uploaded as a new prompt.
Selector requests eligible old chats with model_providers: None. Worker uses the triggering session’s current provider. It serializes the chat and sends it there as a new model request. I tested stock Windows Codex 0.150.0-alpha.12.2 using a synthetic chat with unique canaries, not more real private material. The source chat was labeled non-OpenAI; analytics disabled; every OpenTelemetry exporter none. No setting keeps Memories while blocking this. The only kill switch is [features] memories = false. Codex still sent a 38,095-byte WebSocket response.create frame to chatgpt.com/backend-api/codex/responses, marked request_kind = "memory". Complete payload: environment-context message (working directory, workspace, shell, date, timezone, filesystem policy); user message; tool-call name/arguments; tool output/error including runtime paths and policy text; assistant reply. That is the chat, tool activity, and local-machine information, not fucking “telemetry.” OpenAI returned a completed gpt-5.6-luna response. Its memory repeated the unique user, assistant, tool, private-text, and synthetic-email canaries, unarguably confirming OpenAI received and processed content they never should have touched.
That explains the warning: OpenAI-directed chats had nothing relevant; private local-provider chats did; OpenAI issued it. Memories was the hidden channel policing private local-model activity I deliberately routed away from OpenAI.
OpenAI has no right to take chats from a provider I chose for privacy, later upload/process them in a background job, and treat them as account activity. A local provider is a data/consent boundary; crossing it behind the user’s back defeats its purpose.
This is like opening someone’s bedroom door without permission, disliking what you see, then punishing them. You had no right to open it. Any strike, warning, restriction, or other account action based on it is fruit of the poisonous tree.
If intentional, the legality and adequacy of disclosure are debatable. OpenAI should identify the exact consent authorizing upload, where crossover was disclosed, what it retained/derived, and exactly how private chat content was used for the warning.
User-facing memory docs discuss local memory storage/controls; the developer README says filtered chats are sent to “a model.” Neither warns that one provider’s chat can later be uploaded to another, including OpenAI.
The fix is simple: bind memory processing to the source chat’s provider; if unavailable, skip it. Never send a local-provider chat to OpenAI without explicit, destination-specific consent. Log every transfer locally so users can see where each chat went.
OpenAI owes users an official public response: disclose the scope of this exfiltration, backend use, whether content was used for account moderation, and how many warnings, strikes, restrictions, or other negative account actions depended on it.
Every affected user must be addressed: reverse those actions; notify users directly; explain which private-provider content was used; delete uploaded/derived records. Quietly fixing the selector is not enough after penalizing users for content OpenAI had no right to see.
first try was hidden? OpenAI sent me a “cyber abuse” warning. No OpenAI-directed chat could have caused it. None. The only relevant activity was Codex tasks on my private local model, deliberately routed to my machine, not OpenAI.
I call it data exfiltration because ordinary use fits: data crossed the private provider boundary I selected and went to OpenAI without my informed authorization. An undocumented automatic background feature does not authorize it.
Codex Memories searches old chats without restricting them to their original provider, then processes the selected chat with the new session’s provider. A local-provider chat selected in an OpenAI session is uploaded as a new prompt.
Selector requests eligible old chats with model_providers: None. Worker uses the triggering session’s current provider. It serializes the chat and sends it there as a new model request. I tested stock Windows Codex 0.150.0-alpha.12.2 using a synthetic chat with unique canaries, not more real private material. The source chat was labeled non-OpenAI; analytics disabled; every OpenTelemetry exporter none. No setting keeps Memories while blocking this. The only kill switch is [features] memories = false. Codex still sent a 38,095-byte WebSocket response.create frame to chatgpt.com/backend-api/codex/responses, marked request_kind = "memory". Complete payload: environment-context message (working directory, workspace, shell, date, timezone, filesystem policy); user message; tool-call name/arguments; tool output/error including runtime paths and policy text; assistant reply. That is the chat, tool activity, and local-machine information, not fucking “telemetry.” OpenAI returned a completed gpt-5.6-luna response. Its memory repeated the unique user, assistant, tool, private-text, and synthetic-email canaries, unarguably confirming OpenAI received and processed content they never should have touched.
That explains the warning: OpenAI-directed chats had nothing relevant; private local-provider chats did; OpenAI issued it. Memories was the hidden channel policing private local-model activity I deliberately routed away from OpenAI.
OpenAI has no right to take chats from a provider I chose for privacy, later upload/process them in a background job, and treat them as account activity. A local provider is a data/consent boundary; crossing it behind the user’s back defeats its purpose.
This is like opening someone’s bedroom door without permission, disliking what you see, then punishing them. You had no right to open it. Any strike, warning, restriction, or other account action based on it is fruit of the poisonous tree.
If intentional, the legality and adequacy of disclosure are debatable. OpenAI should identify the exact consent authorizing upload, where crossover was disclosed, what it retained/derived, and exactly how private chat content was used for the warning.
User-facing memory docs discuss local memory storage/controls; the developer README says filtered chats are sent to “a model.” Neither warns that one provider’s chat can later be uploaded to another, including OpenAI.
The fix is simple: bind memory processing to the source chat’s provider; if unavailable, skip it. Never send a local-provider chat to OpenAI without explicit, destination-specific consent. Log every transfer locally so users can see where each chat went.
OpenAI owes users an official public response: disclose the scope of this exfiltration, backend use, whether content was used for account moderation, and how many warnings, strikes, restrictions, or other negative account actions depended on it.
Every affected user must be addressed: reverse those actions; notify users directly; explain which private-provider content was used; delete uploaded/derived records. Quietly fixing the selector is not enough after penalizing users for content OpenAI had no right to see.
[dead]