Projectless scheduled tasks ignore network-enabled sandbox settings

Summary

Standalone projectless scheduled tasks in the ChatGPT desktop app run with a read-only/restricted runtime that blocks outbound network access, even when the user's default Codex configuration is workspace-write with network access enabled.

The same command succeeds:

1. in an interactive Codex task, and
2. in a scheduler-triggered task bound to a trusted local project.

This appears to be a regression in how projectless scheduled tasks select or inherit their sandbox/permission profile.

Environment

• ChatGPT desktop app: 26.707.71524 (build 5263)
• Bundled Codex CLI: 0.144.2
• macOS: 26.5.1 (25F80)
• Scheduled task type: standalone local cron task
• Configured defaults:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

Steps to reproduce

1. Create a standalone scheduled task with no project binding (projectless).
2. Configure it to run locally and execute a normal HTTPS request as its first action, for example:

``bash
curl --fail --silent --show-error --connect-timeout 15 'https://api.open-meteo.com/v1/forecast?...'
``

1. Wait for the scheduler to trigger the task.
2. Observe that the generated projectless task reports a read-only filesystem and restricted network environment.
3. The request fails immediately with:

``
curl: (6) Could not resolve host: api.open-meteo.com
``

1. Retry the identical request in an interactive task: it succeeds.
2. Bind an identical one-shot scheduled task to a trusted local project and trigger it through the scheduler: it also succeeds, fetches the response, and completes normally.

Expected behavior

Per the scheduled-tasks documentation, unattended scheduled tasks should use the user's default sandbox settings. A projectless scheduled task should therefore inherit workspace-write and network_access = true, or expose a clear supported way to select an equivalent runtime.

Actual behavior

The scheduler itself fires correctly, but projectless runs receive a restricted runtime that ignores the configured network-enabled sandbox defaults. The error presents as DNS failure, but repeated DNS retries do not solve it because outbound access is restricted at the runtime level.

Regression evidence

This workflow previously worked without DNS workarounds. The failures began after a desktop-app update/task recreation in early July 2026. Multiple interactive fetch tests were misleading because they ran in a different permission environment from the scheduled projectless task.

Workaround

Create a dedicated trusted local project and bind the scheduled task to it. A scheduler-triggered control run using the identical prompt then completes successfully.

Additional notes

• The issue is not schedule timing: the projectless task is created at the expected time.
• The issue is not the remote API: the identical request works interactively and from a project-bound scheduled task.
• It would help if scheduled-run metadata clearly showed which sandbox configuration source was selected and why.