Windows Codex: reload sandbox/network permissions in existing long-running tasks

[servver24]

Summary

Existing long-running Codex tasks on Windows do not reload updated sandbox and network permissions after the desktop app is restarted.

A task may therefore permanently lose access to its development environment, even though a newly created task receives the updated permissions and works correctly.

Environment

• Product: ChatGPT desktop app with Codex
• OS: Windows
• App version: 26.715.70719
• Connection tested: SSH to a private Debian server on the local network
• Authentication: dedicated Ed25519 key; password authentication disabled

Steps to reproduce

1. Start a Codex task with restricted sandbox or network permissions.
2. Configure authorized SSH access to a private LAN server.
3. Confirm that SSH works from inside the task.
4. Change the global Codex settings to allow filesystem and network access.
5. Restart the Windows desktop app.
6. Reopen the existing long-running task.
7. Attempt the same SSH connection again.
8. Create a new task and repeat the test.

Actual behavior

• The existing task remains tied to its original restricted environment.
• The connection fails locally before SSH authentication.
• Restarting the desktop app does not reload the task permissions.
• A new task receives the changed permissions and can connect successfully.
• The application does not clearly show that effective task permissions differ from the current global settings.

The server remained available, authorized_keys was unchanged, the private key still existed, and no server-side SSH configuration was changed.

Expected behavior

Please provide an explicit option for an existing task:

Restart environment with current permissions

It should preserve:

• the complete conversation and task history;
• project and workspace association;
• plans and checkpoints;
• architecture decisions;
• regression and troubleshooting history;
• references to local files.

It is acceptable to terminate active commands and temporary processes during the restart.

Additional UX and safety suggestions

1. Display the effective filesystem, sandbox, network, and approval permissions for the current task.

2. Clearly warn when permission changes apply only to newly created tasks.

3. Require explicit confirmation before increasing permissions.

4. Support scoped and revocable network access, for example one LAN host and port.

5. Record permission changes in an audit history.

6. Never expose or transfer private-key contents.

7. If an in-place restart is impossible, provide:

   Resume project in a new environment

   This should create a structured handoff containing project decisions, unfinished work, regression history, safety requirements, and workspace references.

Why this matters

Long-running development tasks can contain weeks of important context. Starting a new task with access to the same files does not restore the reasoning behind architectural decisions, fixed regressions, recovery procedures, or safety rules.

Losing this continuity can cause duplicated work, repeated bugs, architectural regressions, and unsafe operations.

Diagnostic reference

Codex Feedback session ID:

019f810b-3d39-74b2-a034-1dfb621f7217

I can provide redacted screenshots and help test a solution on Windows.

As a small bonus request: after discovering this through extensive real-world testing, I would happily accept early access to the improvement, some Codex credits, merchandise, or a “persistent-task tester” badge. 😄
m.orwat at outlook