VS Code extension on native Windows ignores repo-local .codex/config.toml

What version of the IDE extension are you using?

openai.chatgpt-26.5325.21211

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

When using the Codex VS Code extension on native Windows, repo-local .codex/config.toml does not appear to be applied, even though the same config works correctly in Codex CLI from the same repository.

In my case, the following entries from ./.codex/config.toml are ignored by the VS Code extension:

• model_instructions_file
• [[skills.config]]

At the same time, AGENTS.md from the repository is loaded correctly in the extension.

This creates a behavior mismatch:

• Codex CLI started from the repo root correctly loads the repo-local config and custom skill.
• Codex VS Code extension started in the same repo does not.

I verified that:

• the file exists at ./.codex/config.toml
• the relative paths inside it are valid
• the same setup works in Codex CLI
• AGENTS.md is applied in the VS Code extension, so the workspace itself is being detected

Example repo-local config:

#:schema https://developers.openai.com/codex/config-schema.json
model_instructions_file = "../my-workbench/codex/instructions/project-instructions.md"

[[skills.config]]
path = "../my-workbench/codex/skills/lh-workbench-env"
enabled = true

Both referenced paths exist and are valid.

What steps can reproduce the bug?

1. On native Windows, open a repository in VS Code.
2. Add a repo-local .codex/config.toml with:

• model_instructions_file
• [[skills.config]]

1. Make sure the referenced files exist and the same config works in Codex CLI from the repo root.
2. Start a Codex session from the VS Code extension from fresh VS Code instance.
3. Ask Codex which instructions and skills are currently loaded.
4. Compare that with a Codex CLI session started from the same repository.

Minimal reproduction config:

#:schema https://developers.openai.com/codex/config-schema.json
model_instructions_file = "instructions.md"

[[skills.config]]
path = "skills/my-skill"
enabled = true

Repo layout:

repo/
  .codex/
    config.toml
  instructions.md
  skills/
    my-skill/
      SKILL.md
  AGENTS.md

Observed behavior in the VS Code extension:

• AGENTS.md is loaded
• model_instructions_file is not loaded
• [[skills.config]] skill is not registered/available

Observed behavior in Codex CLI:

• all of the above load correctly

What is the expected behavior?

The VS Code extension should apply the same repo-local .codex/config.toml config layer as Codex CLI when launched in the same repository.

Specifically, on native Windows I would expect:

• model_instructions_file from ./.codex/config.toml to be loaded
• [[skills.config]] repo-local skills to be available
• behavior to match Codex CLI for the same repo

Additional information

I investigated the installed extension bundle locally and found what looks like the likely root cause.

In the native Windows code path, the extension appears to spawn codex app-server without setting cwd to the workspace root.

In the installed bundle:

C:\Users\Rinat\scoop\apps\vscode\current\data\extensions\openai.chatgpt-26.5325.21211-win32-x64\out\extension.js

startCodexProcess() calls:

O5(this.extensionUri, "app-server", ["--analytics-default-enabled"])

And the native Windows spawn path appears to do:

spawn(s, u, {
  stdio: ["pipe", "pipe", "pipe"],
  env: { ...process.env, ...o, PATH: c, RUST_LOG: "warn", CODEX_INTERNAL_ORIGINATOR_OVERRIDE: fl }
})

without passing cwd.

By contrast, the WSL code path appears to explicitly set the workspace root via wsl.exe --cd <workspaceRoot> ....

So this looks like a native Windows VS Code extension bug where codex app-server is started without the workspace root as its working directory, which would explain why repo-local .codex/config.toml is not discovered while AGENTS.md still works.

Related note:

• the extension command open-config-toml also appears to open only the global config under ~/.codex/config.toml, which may point to the same global-config-first assumption in the extension UI path.

If useful, I can also provide the exact local code snippets from the installed bundle that point to this behavior.