[Bug]: Codex turns reset sandbox network access to false in Auto and Auto-accept-edits modes

[famesjranko]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On a Linux T3 server, open Settings > Providers for that environment and set Codex "Launch arguments" to -c sandbox_workspace_write.network_access=true.
2. Start a new Codex thread in Auto mode.
3. Ask the agent to run gh api user --jq .login.

Expected behavior

The command runs inside the workspace-write sandbox with network access, because Codex is configured with sandbox_workspace_write.network_access = true.

Actual behavior

The sandbox has no network access. The command fails:

Get "https://api.github.com/user": proxyconnect tcp: dial tcp 127.0.0.1:43117: socket: operation not permitted

The Codex rollout for the turn records "sandbox_policy":{"type":"workspace-write","network_access":false,...}. The codex app-server process does have -c sandbox_workspace_write.network_access=true on its command line.

The thread starts with the correct policy. I sent the same thread/start request that T3 sends (sandbox: "workspace-write", approvalPolicy: "on-request") to a separate codex app-server started with the same -c argument. The response contained "networkAccess": true.

The value changes at the turn. buildTurnStartParams sends sandboxPolicy: runtimeModeToTurnSandboxPolicy(input.runtimeMode) on every turn. For Auto and Auto-accept-edits, that function returns { type: "workspaceWrite" } with no networkAccess field. Codex treats the missing field as false, and the turn policy replaces the thread policy that came from the configuration.

t3code/apps/server/src/provider/Layers/CodexSessionRuntime.ts

Lines 568 to 590 in 6391be2

	function runtimeModeToTurnSandboxPolicy(
	input: RuntimeMode,
	): EffectCodexSchema.V2TurnStartParams__SandboxPolicy {
	switch (input) {
	case "approval-required":
	return {
	type: "readOnly",
	};
	case "auto-accept-edits":
	case "auto":
	return {
	type: "workspaceWrite",
	};
	case "full-access":
	default:
	return {
	type: "dangerFullAccess",
	};
	}
	}
	function buildCodexTurnInstructions(input: {
	readonly interactionMode?: ProviderInteractionMode;

t3code/apps/server/src/provider/Layers/CodexSessionRuntime.ts

Line 666 in 6391be2

sandboxPolicy: runtimeModeToTurnSandboxPolicy(input.runtimeMode),

As a result, the documented Codex setting and T3's own Launch arguments field have no effect in sandboxed modes. The only mode with network access is Full access, which removes the sandbox and all approvals. gh auth status also reports this failure as "The token in ... is invalid", which is misleading.

A possible fix is to build the turn policy from the thread's effective sandbox value, which thread/start returns, and change only its type. Another option is to send sandboxPolicy only when the runtime mode changes. Either option keeps the user's Codex settings for network access and writable roots.

Impact

Major degradation or frequent failure

Version or commit

T3 server 0.0.42; same code on main at 6391be2

Environment

T3 server on Debian 13 as a systemd user service; T3 desktop 0.0.42 on Windows as a remote client; Codex CLI 0.157.0; Auto mode

Logs or stack traces

Codex rollout turn_context for the failing turn:

"approval_policy": "on-request",
"approvals_reviewer": "auto_review",
"sandbox_policy": {"type": "workspace-write", "network_access": false, "exclude_tmpdir_env_var": false, "exclude_slash_tmp": false}

Screenshots, recordings, or supporting files

No response

Workaround

None in a sandboxed mode. Escalated commands can reach the network after approval.

Related: #6415, which asked for Codex sessions to inherit configured permission profiles and was moved to Discussions.

[juliusmarminge]

Triage

Confirmed on current main. This is a bug, and it is not a duplicate of #6415 (that request was to inherit named Codex permission profiles and now lives in discussion #6976).

thread/start and thread/resume only send a sandbox mode. For Auto and Auto-accept-edits that mode is "workspace-write", so Codex resolves sandbox_workspace_write.network_access (and writable roots) from config and launch arguments. That matches the networkAccess: true result from a standalone thread/start with the same -c flag.

Every turn/start then replaces that resolved policy. buildTurnStartParams always sends sandboxPolicy: runtimeModeToTurnSandboxPolicy(runtimeMode), and for both of those modes the policy is only { type: "workspaceWrite" }:

function runtimeModeToTurnSandboxPolicy(
  input: RuntimeMode,
): EffectCodexSchema.V2TurnStartParams__SandboxPolicy {
  switch (input) {
    case "approval-required":
      return { type: "readOnly" };
    case "auto-accept-edits":
    case "auto":
      return { type: "workspaceWrite" };
    // ...
  }
}

turn/start's sandboxPolicy is defined as an override for this turn and subsequent turns. On workspaceWrite, networkAccess defaults to false and writableRoots defaults to [], so the omitted fields wipe the config Codex had already applied. The rollout value "network_access": false is that override, not the launch argument failing to reach codex app-server. Full access is unaffected because dangerFullAccess has no network flag. The gh auth status "token invalid" line is gh misreading the denied proxy dial (127.0.0.1:43117: operation not permitted).

The policy is resent on purpose so a runtime-mode change sticks. A fix should keep that, and preserve the config-resolved workspace-write fields (networkAccess, writableRoots, and the tmp exclusions) instead of hardcoding networkAccess: true. CodexSessionRuntime.test.ts currently expects the bare { type: "workspaceWrite" } policy, so those assertions need to move with the fix.