On Windows you can work with Codex in two ways, and the choice between them is a choice of execution model, not a shell by taste. The native way is PowerShell, the alternative is WSL2. This is not a cosmetic difference: they have different sandbox implementations and different assumptions about paths and runtime. What in WSL2 looks like an ordinary Linux toolchain works differently in native Windows, so you first decide where the work will run and only then configure the details.

Native Windows setup has its own recovery commands. If the CLI runs in a degraded mode, /setup-default-sandbox helps - it brings the sandbox to a working default state. A separate detail: /sandbox-add-read-dir adds an absolute read path only on Windows. This is platform specificity kept in mind: commands and behavior true in WSL2 or on macOS may be named differently or absent on native Windows, and this is checked rather than carried over by analogy.

WSL2 is attractive precisely in that it gives a familiar Linux environment with stronger isolation, but it too has its cost. Paths and runtime inside WSL2 are a Linux world separate from the Windows file system, and mixing them thoughtlessly is a source of confusion with performance and access. Choosing WSL2 is justified when the whole toolchain is Linux anyway; native Windows when the work is tied to Windows tools and scripts. You decide by the nature of the task, not by which shell is more familiar.

A remote connection is a fundamentally different axis: it separates the interface from the execution host. The UI is with you, while the computation runs on a remote machine. This is powerful but opens a whole list of what needs checking before trust: the server address, TLS, the auth token source, the remote current directory, the version and the sandbox on that side. Each of these points is a potential hole: the wrong address, no TLS, a token from the wrong source or an unexpected sandbox on the remote host.

It helps to see a secure connection to a remote host once. Below is codex --remote with a wss:// address and --remote-auth-token-env passing a bearer token from an environment variable. The key detail: --remote-auth-token-env passes the token only to an allowed remote endpoint, and for an external host you need exactly wss:// - a secure transport. A token from the environment rather than the command line, and a secure transport, are the minimum below which a remote connection must not drop.