OpenAI - Codex Docs Changes 2026-04-10 18:23 UTC → 2026-04-13 00:44 UTC

152 152 

153- **macOS** uses Seatbelt policies and runs commands using `sandbox-exec` with a profile (`-p`) that corresponds to the `--sandbox` mode you selected. When restricted read access enables platform defaults, Codex appends a curated macOS platform policy (instead of broadly allowing `/System`) to preserve common tool compatibility.153- **macOS** uses Seatbelt policies and runs commands using `sandbox-exec` with a profile (`-p`) that corresponds to the `--sandbox` mode you selected. When restricted read access enables platform defaults, Codex appends a curated macOS platform policy (instead of broadly allowing `/System`) to preserve common tool compatibility.

154- **Linux** uses the bubblewrap pipeline plus `seccomp` by default. `use_legacy_landlock` is available when you need the older path. In managed proxy mode, the default bubblewrap pipeline routes egress through a proxy-only bridge and fails closed if it cannot build valid loopback proxy routes.154- **Linux** uses the bubblewrap pipeline plus `seccomp` by default. `use_legacy_landlock` is available when you need the older path. In managed proxy mode, the default bubblewrap pipeline routes egress through a proxy-only bridge and fails closed if it cannot build valid loopback proxy routes.

155- **Windows** uses the Linux sandbox implementation when running in [Windows Subsystem for Linux (WSL)](https://developers.openai.com/codex/windows#windows-subsystem-for-linux). When running natively on Windows, Codex uses a [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) implementation.155- **Windows** uses the Linux sandbox implementation when running in [Windows Subsystem for Linux 2 (WSL2)](https://developers.openai.com/codex/windows#windows-subsystem-for-linux). WSL1 was supported through Codex `0.114`; starting in `0.115`, the Linux sandbox moved to `bubblewrap`, so WSL1 is no longer supported. When running natively on Windows, Codex uses a [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) implementation.

156 156 

157If you use the Codex IDE extension on Windows, it supports WSL directly. Set the following in your VS Code settings to keep the agent inside WSL whenever it’s available:157If you use the Codex IDE extension on Windows, it supports WSL2 directly. Set the following in your VS Code settings to keep the agent inside WSL2 whenever it's available:

158 158 

159```json159```json

160{160{

4working across projects, running parallel agent threads, and reviewing results.4working across projects, running parallel agent threads, and reviewing results.

5It runs natively on Windows using PowerShell and the5It runs natively on Windows using PowerShell and the

6[Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox), or you can configure it to6[Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox), or you can configure it to

7run in [Windows Subsystem for Linux (WSL)](#windows-subsystem-for-linux-wsl).7run in [Windows Subsystem for Linux 2 (WSL2)](#windows-subsystem-for-linux-wsl).

8 8 

9![Codex app for Windows showing a project sidebar, active thread, and review pane](/images/codex/windows/codex-windows-light.webp)9![Codex app for Windows showing a project sidebar, active thread, and review pane](/images/codex/windows/codex-windows-light.webp)

10 10 

30 30 

31## Native sandbox31## Native sandbox

32 32 

33The Codex app on Windows supports a native [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) when the agent runs in PowerShell, and uses Linux sandboxing when you run the agent in [Windows Subsystem for Linux (WSL)](#windows-subsystem-for-linux-wsl). To apply sandbox protections in either mode, set sandbox permissions to **Default permissions** in the Composer before sending messages to Codex.33The Codex app on Windows supports a native [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) when the agent runs in PowerShell, and uses Linux sandboxing when you run the agent in [Windows Subsystem for Linux 2 (WSL2)](#windows-subsystem-for-linux-wsl). To apply sandbox protections in either mode, set sandbox permissions to **Default permissions** in the Composer before sending messages to Codex.

34 34 

35Running Codex in full access mode means Codex is not limited to your project35Running Codex in full access mode means Codex is not limited to your project

36 directory and might perform unintentional destructive actions that can lead to36 directory and might perform unintentional destructive actions that can lead to

71 71 

72By default, the Codex app uses the Windows-native agent. That means the agent72By default, the Codex app uses the Windows-native agent. That means the agent

73runs commands in PowerShell. The app can still work with projects that live in73runs commands in PowerShell. The app can still work with projects that live in

74Windows Subsystem for Linux (WSL) by using the `wsl` CLI when needed.74Windows Subsystem for Linux 2 (WSL2) by using the `wsl` CLI when needed.

75 75 

76If you want to add a project from the WSL filesystem, click **Add new project**76If you want to add a project from the WSL filesystem, click **Add new project**

77or press <kbd>Ctrl</kbd>+<kbd>O</kbd>, then type `\\wsl$\` into the File77or press <kbd>Ctrl</kbd>+<kbd>O</kbd>, then type `\\wsl$\` into the File

83`/mnt/<drive>/...`. This setup is more reliable than opening projects83`/mnt/<drive>/...`. This setup is more reliable than opening projects

84directly from the WSL filesystem.84directly from the WSL filesystem.

85 85 

86If you want the agent itself to run in WSL, open **[Settings](codex://settings)**,86If you want the agent itself to run in WSL2, open **[Settings](codex://settings)**,

87switch the agent from Windows native to WSL, and **restart the app**. The87switch the agent from Windows native to WSL, and **restart the app**. The

88change doesn't take effect until you restart. Your projects should remain in88change doesn't take effect until you restart. Your projects should remain in

89place after restart.89place after restart.

90 90 

91WSL1 was supported through Codex `0.114`. Starting in Codex `0.115`, the Linux

92sandbox moved to `bubblewrap`, so WSL1 is no longer supported.

93 

91![Codex app settings showing the agent selector with Windows native and WSL options](/images/codex/windows/wsl-select-light.webp)94![Codex app settings showing the agent selector with Windows native and WSL options](/images/codex/windows/wsl-select-light.webp)

92 95 

93You configure the integrated terminal independently from the agent. See96You configure the integrated terminal independently from the agent. See

44 npm i -g @openai/codex@latestCopy44 npm i -g @openai/codex@latestCopy

45 45 

46The Codex CLI is available on macOS and Linux. Windows support is46The Codex CLI is available on macOS and Linux. Windows support is

47experimental. For the best Windows experience, use Codex in a WSL workspace47experimental. For the best Windows experience, use Codex in a WSL2 workspace

48and follow our [Windows setup guide](https://developers.openai.com/codex/windows).48and follow our [Windows setup guide](https://developers.openai.com/codex/windows).

49 49 

50If you're new to Codex, read the [best practices guide](https://developers.openai.com/codex/learn/best-practices).50If you're new to Codex, read the [best practices guide](https://developers.openai.com/codex/learn/best-practices).

44 44 

45Each resumed run keeps the original transcript, plan history, and approvals, so Codex can use prior context while you supply new instructions. Override the working directory with `--cd` or add extra roots with `--add-dir` if you need to steer the environment before resuming.45Each resumed run keeps the original transcript, plan history, and approvals, so Codex can use prior context while you supply new instructions. Override the working directory with `--cd` or add extra roots with `--add-dir` if you need to steer the environment before resuming.

46 46 

47## Connect the TUI to a remote app server

48 

49Remote TUI mode lets you run the Codex app server on one machine and use the Codex terminal UI from another machine. This is useful when the code, credentials, or execution environment live on a remote host, but you want the local interactive TUI experience.

50 

51Start the app server on the machine that should own the workspace and run commands:

52 

53```bash

54codex app-server --listen ws://127.0.0.1:4500

55```

56 

57Then connect from the machine running the TUI:

58 

59```bash

60codex --remote ws://127.0.0.1:4500

61```

62 

63For access from another machine, bind the app server to a reachable interface, for example:

64 

65```bash

66codex app-server --listen ws://0.0.0.0:4500

67```

68 

69`--remote` accepts explicit `ws://host:port` and `wss://host:port` addresses only. For plain WebSocket connections, prefer local-host addresses or SSH port forwarding. If you expose the listener beyond the local host, configure authentication before real remote use and put authenticated non-local connections behind TLS.

70 

71Codex supports these WebSocket authentication modes for remote TUI connections:

72 

73- **No WebSocket auth**: Best for local-host listeners or SSH port-forwarded connections. Codex can start non-local listeners without auth, but logs a warning and the startup banner reminds you to configure auth before real remote use.

74- **Capability token**: Store a shared token in a file on the app-server host, start the server with `--ws-auth capability-token --ws-token-file /abs/path/to/token`, then set the same token in an environment variable on the TUI host and pass `--remote-auth-token-env <ENV_VAR>`.

75- **Signed bearer token**: Store an HMAC shared secret in a file on the app-server host, start the server with `--ws-auth signed-bearer-token --ws-shared-secret-file /abs/path/to/secret`, and have the TUI send a signed JWT bearer token through `--remote-auth-token-env <ENV_VAR>`. The shared secret must be at least 32 bytes. Signed tokens use HS256 and must include `exp`; Codex also validates `nbf`, `iss`, and `aud` when those claims or server options are present.

76 

77To create a capability token on the app-server host, generate a random token file with permissions that only your user can read:

78 

79```bash

80TOKEN_FILE="$HOME/.codex/codex-app-server-token"

81install -d -m 700 "$(dirname "$TOKEN_FILE")"

82openssl rand -base64 32 > "$TOKEN_FILE"

83chmod 600 "$TOKEN_FILE"

84```

85 

86Treat the token file like a password, and regenerate it if it leaks.

87 

88Then start the app server with that token file. For example, with a capability token behind a TLS proxy:

89 

90```bash

91# Remote host

92TOKEN_FILE="$HOME/.codex/codex-app-server-token"

93codex app-server \

94 --listen ws://0.0.0.0:4500 \

95 --ws-auth capability-token \

96 --ws-token-file "$TOKEN_FILE"

97 

98# TUI host

99export CODEX_REMOTE_AUTH_TOKEN="$(ssh devbox 'cat ~/.codex/codex-app-server-token')"

100codex --remote wss://codex-devbox.example.com:4500 \

101 --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN

102```

103 

104The TUI sends remote auth tokens as `Authorization: Bearer <token>` during the WebSocket handshake. Codex only sends those tokens over `wss://` URLs or `ws://` URLs whose host is `localhost`, `127.0.0.1`, or `::1`, so put non-local remote listeners behind TLS if clients need to authenticate over the network.

105 

47## Models and reasoning106## Models and reasoning

48 107 

49For most tasks in Codex, `gpt-5.4` is the recommended model. It brings the108For most tasks in Codex, `gpt-5.4` is the recommended model. It brings the

26| `--no-alt-screen` | `boolean` | Disable alternate screen mode for the TUI (overrides `tui.alternate_screen` for this run). |26| `--no-alt-screen` | `boolean` | Disable alternate screen mode for the TUI (overrides `tui.alternate_screen` for this run). |

27| `--oss` | `boolean` | Use the local open source model provider (equivalent to `-c model_provider="oss"`). Validates that Ollama is running. |27| `--oss` | `boolean` | Use the local open source model provider (equivalent to `-c model_provider="oss"`). Validates that Ollama is running. |

28| `--profile, -p` | `string` | Configuration profile name to load from `~/.codex/config.toml`. |28| `--profile, -p` | `string` | Configuration profile name to load from `~/.codex/config.toml`. |

29| `--remote` | `ws://host:port | wss://host:port` | Connect the interactive TUI to a remote app-server WebSocket endpoint. Supported for `codex`, `codex resume`, and `codex fork`; other subcommands reject remote mode. |

30| `--remote-auth-token-env` | `ENV_VAR` | Read a bearer token from this environment variable and send it when connecting with `--remote`. Requires `--remote`; tokens are only sent over `wss://` URLs or `ws://` URLs whose host is `localhost`, `127.0.0.1`, or `::1`. |

29| `--sandbox, -s` | `read-only | workspace-write | danger-full-access` | Select the sandbox policy for model-generated shell commands. |31| `--sandbox, -s` | `read-only | workspace-write | danger-full-access` | Select the sandbox policy for model-generated shell commands. |

30| `--search` | `boolean` | Enable live web search (sets `web_search = "live"` instead of the default `"cached"`). |32| `--search` | `boolean` | Enable live web search (sets `web_search = "live"` instead of the default `"cached"`). |

31| `PROMPT` | `string` | Optional text instruction to start the session. Omit to launch the TUI without a pre-filled message. |33| `PROMPT` | `string` | Optional text instruction to start the session. Omit to launch the TUI without a pre-filled message. |

188 190 

189Key191Key

190 192 

193`--remote`

194 

195Type / Values

196 

197`ws://host:port | wss://host:port`

198 

199Details

200 

201Connect the interactive TUI to a remote app-server WebSocket endpoint. Supported for `codex`, `codex resume`, and `codex fork`; other subcommands reject remote mode.

202 

203Key

204 

205`--remote-auth-token-env`

206 

207Type / Values

208 

209`ENV_VAR`

210 

211Details

212 

213Read a bearer token from this environment variable and send it when connecting with `--remote`. Requires `--remote`; tokens are only sent over `wss://` URLs or `ws://` URLs whose host is `localhost`, `127.0.0.1`, or `::1`.

214 

215Key

216 

191`--sandbox, -s`217`--sandbox, -s`

192 218 

193Type / Values219Type / Values

251| [`codex mcp`](https://developers.openai.com/codex/cli/reference#codex-mcp) | Experimental | Manage Model Context Protocol servers (list, add, remove, authenticate). |277| [`codex mcp`](https://developers.openai.com/codex/cli/reference#codex-mcp) | Experimental | Manage Model Context Protocol servers (list, add, remove, authenticate). |

252| [`codex mcp-server`](https://developers.openai.com/codex/cli/reference#codex-mcp-server) | Experimental | Run Codex itself as an MCP server over stdio. Useful when another agent consumes Codex. |278| [`codex mcp-server`](https://developers.openai.com/codex/cli/reference#codex-mcp-server) | Experimental | Run Codex itself as an MCP server over stdio. Useful when another agent consumes Codex. |

253| [`codex resume`](https://developers.openai.com/codex/cli/reference#codex-resume) | Stable | Continue a previous interactive session by ID or resume the most recent conversation. |279| [`codex resume`](https://developers.openai.com/codex/cli/reference#codex-resume) | Stable | Continue a previous interactive session by ID or resume the most recent conversation. |

254| [`codex sandbox`](https://developers.openai.com/codex/cli/reference#codex-sandbox) | Experimental | Run arbitrary commands inside Codex-provided macOS seatbelt or Linux sandboxes (Landlock by default, optional bubblewrap pipeline). |280| [`codex sandbox`](https://developers.openai.com/codex/cli/reference#codex-sandbox) | Experimental | Run arbitrary commands inside Codex-provided macOS seatbelt or Linux bubblewrap sandboxes. |

255 281 

256Key282Key

257 283 

455 481 

456Details482Details

457 483 

458Run arbitrary commands inside Codex-provided macOS seatbelt or Linux sandboxes (Landlock by default, optional bubblewrap pipeline).484Run arbitrary commands inside Codex-provided macOS seatbelt or Linux bubblewrap sandboxes.

459 485 

460Expand to view all486Expand to view all

461 487 

465 491 

466Running `codex` with no subcommand launches the interactive terminal UI (TUI). The agent accepts the global flags above plus image attachments. Web search defaults to cached mode; use `--search` to switch to live browsing and `--full-auto` to let Codex run most commands without prompts.492Running `codex` with no subcommand launches the interactive terminal UI (TUI). The agent accepts the global flags above plus image attachments. Web search defaults to cached mode; use `--search` to switch to live browsing and `--full-auto` to let Codex run most commands without prompts.

467 493 

494Use `--remote ws://host:port` or `--remote wss://host:port` to connect the TUI to an app server started with `codex app-server --listen ws://IP:PORT`. Add `--remote-auth-token-env <ENV_VAR>` when the server requires a bearer token for WebSocket authentication. See [Codex CLI features](https://developers.openai.com/codex/cli/features#connect-the-tui-to-a-remote-app-server) for setup examples and authentication guidance.

495 

468### `codex app-server`496### `codex app-server`

469 497 

470Launch the Codex app server locally. This is primarily for development and debugging and may change without notice.498Launch the Codex app server locally. This is primarily for development and debugging and may change without notice.

471 499 

472| Key | Type / Values | Details |500| Key | Type / Values | Details |

473| --- | --- | --- |501| --- | --- | --- |

474| `--listen` | `stdio:// | ws://IP:PORT` | Transport listener URL. `ws://` is experimental and intended for development/testing. |502| `--listen` | `stdio:// | ws://IP:PORT` | Transport listener URL. Use `ws://IP:PORT` to expose a WebSocket endpoint for remote clients. |

503| `--ws-audience` | `string` | Expected `aud` claim for signed bearer tokens. Requires `--ws-auth signed-bearer-token`. |

504| `--ws-auth` | `capability-token | signed-bearer-token` | Authentication mode for app-server WebSocket clients. If omitted, WebSocket auth is disabled; non-local listeners warn during startup. |

505| `--ws-issuer` | `string` | Expected `iss` claim for signed bearer tokens. Requires `--ws-auth signed-bearer-token`. |

506| `--ws-max-clock-skew-seconds` | `number` | Clock skew allowance when validating signed bearer token `exp` and `nbf` claims. Requires `--ws-auth signed-bearer-token`. |

507| `--ws-shared-secret-file` | `absolute path` | File containing the HMAC shared secret used to validate signed JWT bearer tokens. Required with `--ws-auth signed-bearer-token`. |

508| `--ws-token-file` | `absolute path` | File containing the shared capability token. Required with `--ws-auth capability-token`. |

475 509 

476Key510Key

477 511 

483 517 

484Details518Details

485 519 

486Transport listener URL. `ws://` is experimental and intended for development/testing.520Transport listener URL. Use `ws://IP:PORT` to expose a WebSocket endpoint for remote clients.

521 

522Key

523 

524`--ws-audience`

525 

526Type / Values

527 

528`string`

529 

530Details

531 

532Expected `aud` claim for signed bearer tokens. Requires `--ws-auth signed-bearer-token`.

533 

534Key

535 

536`--ws-auth`

537 

538Type / Values

539 

540`capability-token | signed-bearer-token`

541 

542Details

543 

544Authentication mode for app-server WebSocket clients. If omitted, WebSocket auth is disabled; non-local listeners warn during startup.

545 

546Key

547 

548`--ws-issuer`

549 

550Type / Values

551 

552`string`

553 

554Details

555 

556Expected `iss` claim for signed bearer tokens. Requires `--ws-auth signed-bearer-token`.

557 

558Key

559 

560`--ws-max-clock-skew-seconds`

561 

562Type / Values

563 

564`number`

565 

566Details

567 

568Clock skew allowance when validating signed bearer token `exp` and `nbf` claims. Requires `--ws-auth signed-bearer-token`.

569 

570Key

571 

572`--ws-shared-secret-file`

573 

574Type / Values

575 

576`absolute path`

577 

578Details

579 

580File containing the HMAC shared secret used to validate signed JWT bearer tokens. Required with `--ws-auth signed-bearer-token`.

581 

582Key

583 

584`--ws-token-file`

585 

586Type / Values

587 

588`absolute path`

589 

590Details

591 

592File containing the shared capability token. Required with `--ws-auth capability-token`.

487 593 

488`codex app-server --listen stdio://` keeps the default JSONL-over-stdio behavior. `--listen ws://IP:PORT` enables WebSocket transport (experimental). If you generate schemas for client bindings, add `--experimental` to include gated fields and methods.594`codex app-server --listen stdio://` keeps the default JSONL-over-stdio behavior. `--listen ws://IP:PORT` enables WebSocket transport for app-server clients. The server accepts `ws://` listen URLs; use TLS termination or a secure proxy when clients connect with `wss://`. If you generate schemas for client bindings, add `--experimental` to include gated fields and methods.

489 595 

490### `codex app`596### `codex app`

491 597 

21those commands inherit the same sandbox boundaries.21those commands inherit the same sandbox boundaries.

22 22 

23Codex uses platform-native enforcement on each OS. The implementation differs23Codex uses platform-native enforcement on each OS. The implementation differs

24between macOS, Linux, WSL, and native Windows, but the idea is the same across24between macOS, Linux, WSL2, and native Windows, but the idea is the same across

25surfaces: give the agent a bounded place to work so routine tasks can run25surfaces: give the agent a bounded place to work so routine tasks can run

26autonomously inside clear limits.26autonomously inside clear limits.

27 27 

60sudo dnf install bubblewrap60sudo dnf install bubblewrap

61```61```

62 62 

63Codex uses the system `bwrap` at `/usr/bin/bwrap` when it is available. If it63Codex uses the first `bwrap` executable it finds on `PATH`. If no `bwrap`

64is missing, Codex falls back to a bundled helper, but that helper requires64executable is available, Codex falls back to a bundled helper, but that helper

65unprivileged user namespaces. Installing your distro’s `bubblewrap` package is65requires unprivileged user namespaces. Installing your distro’s `bubblewrap`

66the most reliable setup.66package keeps this setup reliable.

67 67 

68Codex surfaces a startup warning when `bwrap` is missing or cannot create user68Codex surfaces a startup warning when `bwrap` is missing or cannot create user

69namespaces. On distributions that restrict them with AppArmor, you can enable69namespaces. On distributions that restrict them with AppArmor, you can enable

17- [Download for JetBrains IDEs](#jetbrains-ide-integration)17- [Download for JetBrains IDEs](#jetbrains-ide-integration)

18 18 

19The Codex VS Code extension is available on macOS and Linux. Windows support19The Codex VS Code extension is available on macOS and Linux. Windows support

20is experimental. For the best Windows experience, use Codex in a WSL workspace20is experimental. For the best Windows experience, use Codex in a WSL2

21and follow our [Windows setup guide](https://developers.openai.com/codex/windows).21workspace and follow our [Windows setup guide](https://developers.openai.com/codex/windows).

22 22 

23After you install it, you'll find Codex in your editor sidebar.23After you install it, you'll find Codex in your editor sidebar.

24In VS Code, Codex opens in the right sidebar by default.24In VS Code, Codex opens in the right sidebar by default.

14 14 

15- natively on Windows with the stronger `elevated` sandbox,15- natively on Windows with the stronger `elevated` sandbox,

16- natively on Windows with the fallback `unelevated` sandbox,16- natively on Windows with the fallback `unelevated` sandbox,

17- or inside [Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) (WSL), which uses the Linux sandbox implementation.17- or inside [Windows Subsystem for Linux 2](https://learn.microsoft.com/en-us/windows/wsl/install) (WSL2), which uses the Linux sandbox implementation.

18 18 

19## Windows sandbox19## Windows sandbox

20 20 

85 85 

86The path must be an existing absolute directory. After the command succeeds, later commands that run in the sandbox can read that directory during the current session.86The path must be an existing absolute directory. After the command succeeds, later commands that run in the sandbox can read that directory during the current session.

87 87 

88We recommend using the native Windows sandbox by default. The native Windows sandbox will offer the best perfomance and highest speeds while keeping the same security. Choose WSL when you88We recommend using the native Windows sandbox by default. The native Windows sandbox will offer the best perfomance and highest speeds while keeping the same security. Choose WSL2 when you

89need a Linux-native environment on Windows, when your workflow already lives in89need a Linux-native environment on Windows, when your workflow already lives in

90WSL, or when neither native Windows sandbox mode meets your needs.90WSL2, or when neither native Windows sandbox mode meets your needs.

91 91 

92## Windows Subsystem for Linux92## Windows Subsystem for Linux

93 93 

94If you choose WSL, Codex runs inside the Linux environment instead of using the94If you choose WSL2, Codex runs inside the Linux environment instead of using the

95native Windows sandbox. This is useful if you need Linux-native tooling on95native Windows sandbox. This is useful if you need Linux-native tooling on

96Windows, if your repositories and developer workflow already live in WSL, or96Windows, if your repositories and developer workflow already live in WSL2, or

97if neither native Windows sandbox mode works for your environment.97if neither native Windows sandbox mode works for your environment.

98 98 

99WSL1 was supported through Codex `0.114`. Starting in Codex `0.115`, the Linux

100sandbox moved to `bubblewrap`, so WSL1 is no longer supported.

101 

99### Launch VS Code from inside WSL102### Launch VS Code from inside WSL

100 103 

101For step-by-step instructions, see the [official VS Code WSL tutorial](https://code.visualstudio.com/docs/remote/wsl-tutorial).104For step-by-step instructions, see the [official VS Code WSL tutorial](https://code.visualstudio.com/docs/remote/wsl-tutorial).