Better WSL compatibility in Codex App for Windows, with configurable worktree directory

Open 💬 1 comment Opened Mar 12, 2026 by matheuspimentaa

What variant of Codex are you using?

App

What feature would you like to see?

I would like to request a major improvement to Codex App’s WSL compatibility for Windows users.

Right now, for those of us who work with projects inside WSL and rely on Linux-based development tools, the experience in Codex App is still very limited and ends up hurting the workflow significantly.

The main improvements I would like to see are:

  1. Better performance when opening projects inside the WSL filesystem

Currently, when a project is located inside WSL, Codex App becomes slow. For users who use WSL as their primary development environment, this makes the app much harder to use in day-to-day work.

  1. Better integration between Codex App on Windows and an agent running inside WSL

When the project is located in the Windows filesystem and the agent is configured to run in WSL, the workflow is also poor, because other tools start suffering from the Windows/Linux bridge overhead. This affects the combined use of IDEs, terminals, and other CLIs.

  1. Configurable control over where Codex App creates worktrees

This is one of the most important points. Right now, when I work with a project in WSL, Codex App creates worktrees inside the Windows filesystem. I would like to be able to explicitly configure where those worktrees are created, ideally through something like a configurable Codex Home or a base directory setting for worktrees.

  1. More consistent behavior for hybrid Windows + WSL workflows

Many Windows users follow a hybrid workflow: Codex App on Windows, agent running in WSL, plus other CLI tools such as Codex CLI and other Linux-first tools. It would be very valuable to have stronger support for this setup, without performance loss and without inconsistent worktree behavior.

In summary, I would like to see:

  • better performance with projects in WSL;
  • better integration between the Windows app and the WSL environment;
  • the ability to choose where worktrees are created;
  • more solid support for hybrid workflows using app + CLI + WSL.

This would significantly improve the experience for developers who use Windows as the host OS but WSL as their real engineering environment.

Additional information

My use case is the following:

  • I use Windows as my main operating system.
  • My actual development environment is inside WSL.
  • I also use CLI tools inside WSL, including parallel workflows with worktrees.
  • I want to use Codex App together with that environment, not as something disconnected from it.

Right now, I run into two major problems:

  • If I open the project directly from WSL, Codex App becomes slow.
  • If I move the project to the Windows filesystem to improve app performance, the rest of the workflow with Linux/WSL tools and IDEs also gets worse because of the bridge between the two environments.

On top of that, the current behavior of creating worktrees in the Windows filesystem, even when the project is being used from a WSL context, breaks workflow consistency quite a bit.

For advanced users working on Windows with WSL as their primary development environment, it would be extremely important to have:

  • real compatibility with WSL paths;
  • the ability to choose the base directory for worktrees;
  • more explicit control over where Codex App operates;
  • better performance in WSL-first scenarios.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗