Workspace-write Turns Off Network Access

The mistake

Running Codex under workspace-write and assuming that, because it can read and write files freely inside the project, it can also reach the network the same way an ordinary shell session on your machine could — installing a dependency, calling an internal API, fetching a file over HTTP as part of a task.

Why this happens

Filesystem access and network access are two separate switches, not one combined "how much can Codex do" dial, and workspace-write only flips the first one on by default. Network access stays off unless it's explicitly enabled in configuration. It's an easy assumption to make precisely because the mode already feels permissive — free read/write inside the workspace reads, intuitively, like "the safe stuff is unlocked" — but network calls carry a different kind of risk (exfiltration, fetching and running arbitrary remote content) than editing a file already sitting inside your own repository, which is exactly why they're gated independently.

Why it matters

The failure shows up as a task that looks like it should work — install this package, call this endpoint — failing partway through, in a way that reads like a tooling or connectivity bug rather than a deliberate default. That's a worse debugging experience than an obvious permission error, because the natural instinct is to check the command itself, not the sandbox setting that's actually blocking it.

The fix

If a task genuinely needs network access under workspace-write, enable it explicitly in configuration rather than assuming write access implies it. Do this deliberately, task by task or project by project, rather than reflexively — the default exists because most edit-and-run work inside a workspace doesn't actually need outbound network calls, and leaving it off is the safer posture until you know a specific task requires otherwise.

It's worth deciding this per project rather than once globally, too. A project that legitimately needs outbound calls as part of its normal workflow — hitting an internal service during tests, say — is a reasonable candidate for enabling network access in its own configuration. A general-purpose scratch environment you reuse across unrelated tasks is a much better candidate for leaving it off by default and opting in only when a specific task actually needs it, since a stale blanket allowance is easy to forget about once it's no longer relevant to what you're doing.

See also

Why Workspace-Write Still Blocks Network Access covers the reasoning behind the split in more depth, including how it interacts with the approval flow when a command does try to reach the network unexpectedly.