›_ Codex Issues
Codex Issues / #29866

Codex IDE chat loses SSH/network access after idle/resume in same conversation

Resolved 💬 4 comments Opened Jun 24, 2026 by AuricTW Closed Aug 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt@26.5616.81150

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code 1.125.1

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In the same Codex IDE chat/session, SSH/network access works initially but is lost after returning to the chat later.

Earlier in the same conversation, Codex successfully connected to a LAN SSH host at 192.168.1.250 and started/monitored a long-running benchmark.

After leaving the chat idle and coming back later, the same conversation could no longer access the same SSH/network target.

Observed errors:

  • Paramiko SSH failed with:

PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions.

  • Test-NetConnection 192.168.1.250 -Port 22 returned False.

Expected:
A resumed Codex IDE chat should preserve the same SSH/network capability, or clearly indicate that the sandbox/network permission profile changed.

Impact:
Long-running remote benchmark monitoring becomes unreliable because Codex can start a remote run successfully, but later cannot reconnect to inspect run.log, summary.csv, or per-sample outputs.

This appears to be a Codex IDE session/resume or sandbox/network permission issue, not a remote SSH server issue, because SSH worked earlier in the same chat.

What steps can reproduce the bug?

  1. Open VS Code with the Codex IDE extension.
  2. Start a Codex chat in a local workspace.
  3. Ask Codex to connect to a LAN SSH host and run a remote command, for example:

"Connect to SSH host auriclee-dgx and run: hostname && whoami"

  1. Confirm Codex can successfully connect over SSH.
  2. In the same Codex chat, ask Codex to start or monitor a long-running remote command, for example a benchmark that writes logs on the remote host.
  3. Leave the chat idle for some time, then return to the same chat.
  4. Ask Codex to reconnect to the same SSH host or inspect the same remote run logs.
  5. The resumed chat can no longer access the SSH/network target.

Example commands used by Codex before the issue:

  • SSH target: auriclee@192.168.1.250

Observed after resume:

  • Paramiko SSH failed with:

PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions.

  • Test-NetConnection 192.168.1.250 -Port 22 returned False.

Expected:
The same chat should keep the same network/SSH capability after idle/resume, or clearly report that the sandbox/network permission profile changed.

What is the expected behavior?

A Codex IDE chat that already had SSH/network access should preserve that capability after the chat is resumed from idle.

If the sandbox or network permission profile changes during resume, Codex should clearly report that the environment changed and that existing SSH/network access is no longer available.

The same remote SSH host should remain reachable from Codex in the same conversation, so long-running remote jobs can be monitored after returning to the chat.

Additional information

This affects long-running remote workflows. In this case, Codex successfully started a remote benchmark over SSH, but later could not reconnect in the same chat to inspect run.log, summary.csv, or per-sample result files.

The failure appeared after returning to the same chat later, not at the beginning of the workflow.

No remote SSH server change was made between the successful connection and the later failure.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #28296
  • #29610
  • #29129

Powered by Codex Action

AuricTW · 2 months ago

Potentially related to #28296 and #29610, but I am reporting this separately because my repro is in the IDE extension and the visible regression is loss of SSH/TCP access to a LAN host after idle/resume in the same chat.

AuricTW · 2 months ago

I re-tested this after the recent fix/update and I can no longer reproduce the issue.

In the same Codex IDE chat/session, Codex was able to open an SSH connection to the same LAN host that previously failed with WinError 10013.

SSH/network access works again from Codex, so I am closing this issue as resolved. Thanks.

AuricTW · 1 month ago

Reopening because this has reproduced again, now with stronger local evidence that the failure is caused by stale per-thread sandbox permissions rather than by the SSH server or Windows networking.

New environment/evidence

  • Windows 11: Microsoft Windows NT 10.0.26200.0 x64
  • Codex Desktop package path observed in the sandbox log: OpenAI.Codex_26.707.6957.0_x64
  • Affected thread: 019f5ac1-aafc-7a00-b146-ddfb01c005b7
  • Global/app-visible mode: agent-mode-by-host-id.local = full-access
  • User config contains:

``toml
[windows]
sandbox = "elevated"
``

However, .codex-global-state.json persisted this thread under heartbeat-thread-permissions-by-id as:

approvalPolicy = never
sandboxPolicy.type = workspaceWrite
sandboxPolicy.networkAccess = false
activePermissionProfile = :workspace

Permission transition captured in logs_2.sqlite

2026-07-13 17:14:55  Never | WorkspaceWrite | network_access=false
2026-07-13 17:17:11  Never | DangerFullAccess
2026-07-14 04:21:43  Submission: ThreadRollback { num_turns: 1 }
2026-07-14 04:21:44  UserInput ThreadSettingsOverrides:
                     approval_policy=Never
                     permission_profile=Managed
                     network=Restricted
2026-07-14 04:21:44  Effective runtime:
                     WorkspaceWrite | network_access=false

Immediately after ThreadRollback, the next user-input submission explicitly carried the managed/restricted permission profile. This overrode both the visible Full Access mode and the global Windows sandbox setting.

The effects were broader than one SSH destination:

  • Paramiko failed before connecting with PermissionError: [WinError 10013].
  • Fetching the official Codex manual with curl.exe also failed immediately because outbound sockets were blocked.
  • When the same thread temporarily ran with DangerFullAccess, SSH worked again.
  • After rollback/resume restored the stale heartbeat permission entry, network access failed again.

This suggests the Desktop/IDE client is reapplying stale task-level permissions from heartbeat-thread-permissions-by-id during rollback/resume. The sandbox runner appears to be enforcing the policy it was given; the likely fault is in client-side permission persistence or propagation.

This looks closely related to #29693 and #25810, but this reproduction specifically adds ThreadRollback as a trigger and shows the exact permission transition in runtime logs.

I did not attach the complete global-state or SQLite files because they contain unrelated prompt, repository, and host metadata. I can provide further sanitized excerpts if maintainers need them.