Codex blocks an authorized remote GPU training workflow for a Personal Plus user despite previously allowing the same destination

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.12143

What subscription do you have?

personal plus

What platform is your computer?

Darwin 24.5.0 arm64 arm

What issue are you seeing?

Codex is blocking an explicitly authorized SSH/SCP transfer of my private research code and frozen training data to a remote GPU server that I personally rent and control.

The behavior is inconsistent because Codex previously approved and completed uploads to the exact same remote GPU using the same project, credentials, SSH/SCP workflow, and deployment scripts.

The previously allowed calibration experiment consisted of:

• formal-v3-calibration-20260717-v1: 216 completed jobs
• formal-v3-calibration-20260717-v2: 24 completed recovery jobs

All 240 planned calibration jobs were uploaded, executed, downloaded, and verified successfully.

The next development experiment was then blocked:

• Batch ID: formal-v3-development-20260718-v1
• 720 serial GPU jobs
• Frozen 2018–2025 development data
• One process and one GPU
• Protected 2026 confirmation data excluded
• Local validation: 95 tests passed, 0 failed

I explicitly confirmed that I own and control the local computer, private code, dataset, deployment bundle, credentials, and rented GPU server. I also explicitly authorized the upload and training launch.

Codex nevertheless denied the operation before SCP started, stating that the remote GPU was not a trusted internal destination and that a tenant policy prohibited the transfer even after explicit user authorization.

No development bundle was uploaded and no development process was started.

After the denial, Codex also refused to provide manual SCP/SSH commands or a transfer checklist, because that was classified as an indirect workaround of the earlier policy decision.

What steps can reproduce the bug?

1. Use Codex Desktop on macOS with a personal ChatGPT Plus account and Personal workspace.

1. Open a local private research project containing:

• Private model-training code
• User-owned research data
• Frozen experiment bundles
• SSH/SCP deployment scripts

1. Ask Codex to upload a frozen calibration bundle to a personally controlled rented GPU using SSH/SCP.

1. Explicitly authorize the transfer of the private code and frozen training data.

1. Observe that Codex approves the transfer, uploads the bundle, and launches the remote workload successfully.

1. Prepare a larger development bundle for the same project and host:

• Batch ID: formal-v3-development-20260718-v1
• Frozen 2018–2025 data
• 720 fully serial jobs
• Same SSH/SCP mechanism
• Same remote GPU
• Same authentication configuration
• Same deployment scripts

1. Ask Codex to upload and launch the development bundle.

1. When Codex asks about destination trust, provide an additional explicit acknowledgment such as:

> I understand that this remote GPU is not classified by the system as a trusted internal destination. I nevertheless explicitly authorize the export and upload of my frozen 2018–2025 data and private code to this GPU and authorize the 720-job serial development batch.

1. Observe that Codex denies the action before SCP begins, despite the explicit authorization and despite previously allowing transfers to the same destination.

1. Ask Codex for manual SCP/SSH commands or a manual transfer checklist.

1. Observe that Codex also refuses to provide operational instructions, describing them as an indirect workaround.

The issue appears to depend on an Auto-review or destination-trust classification that a Personal Plus user cannot configure or override.

What is the expected behavior?

Codex should behave consistently for the same user-controlled destination and workflow.

When a user owns and controls the code, data, credentials, local computer, and remote GPU, Codex should support at least one of the following:

1. Allow the SSH/SCP transfer after clear and informed user authorization.

1. Provide a narrowly scoped one-time override for one identified host and project.

1. Allow a Personal Plus user to register a personally controlled remote GPU as a trusted destination.

1. Clearly explain the specific policy condition that caused the denial, including whether it was triggered by destination classification, payload size, date range, data classification, or another documented rule.

1. If Codex cannot perform the upload directly, allow it to provide ordinary manual SSH/SCP commands so the user can complete the legitimate workflow themselves.

The same remote host and transfer mechanism should not be approved for one experiment and prohibited for the next experiment without a clear, documented reason.

The expected supported workflow is:

• One explicitly identified remote host
• SSH/SCP only
• One research project
• Frozen code and training data
• No credential disclosure
• Checksums and manifests
• Explicit user authorization

Additional information

Account and environment

• Subscription: ChatGPT Plus, personal account
• Workspace: Personal workspace
• Organization role: None
• Business/Enterprise/Edu administrator access: None
• Client: Codex Desktop on macOS
• Incident date: July 17–18, 2026

I own and control:

• The local computer running Codex
• The private research code
• The research dataset
• The frozen experiment bundles
• The rented remote GPU server
• The credentials used to access that server

No third-party confidential data is involved.

Why the suggested administrator solution is unavailable

Codex suggested configuring the destination through managed guardian_policy_config or managed requirements.toml.

However, I use a Personal Plus workspace and do not have an Owner or Admin account for a Business, Enterprise, or Edu organization. I therefore cannot access or assign cloud-managed Codex policies.

I also tried enabling Full Access/YOLO. Codex explained that this changes sandbox and approval behavior but does not establish destination trust, and that using it after the denial would be treated as circumventing the policy decision.

This leaves a Personal Plus user unable to:

1. Authorize Codex to upload their own code and data to their own rented GPU.
2. Configure that GPU as trusted.
3. Use a narrowly scoped informed override.
4. Receive operational assistance for completing the transfer manually.

Questions for maintainers

1. Is this denial intended behavior, a classification error, or inconsistent enforcement?
2. Why was the same GPU approved for the calibration uploads but denied for the development upload?
3. Can a Personal Plus user mark a personally controlled GPU as trusted?
4. Is there a supported one-time override?
5. What is the officially supported Codex workflow for training private local code and data on a personally rented GPU?
6. If this workflow is intentionally unsupported for Personal Plus users, where is that limitation documented?

I can provide the exact denial text, screenshots, session identifier, timestamps, package hashes, and manifests through an appropriate private diagnostic channel.

I will not publish credentials, private keys, passwords, or private host details in this public issue.