›_ Codex Issues
Codex Issues / #9770

Bug: VSCode extension duplicates config.toml content on startup

Open 💬 3 comments Opened Jan 23, 2026 by albertodimas
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Description

The VSCode Codex extension appends the entire config.toml content to itself every time VSCode starts or restarts, causing TOML parse errors due to duplicate keys.

Environment

  • VSCode Extension version: 0.5.63
  • Codex CLI version: 0.89.0
  • OS: Ubuntu 24.04 Linux
  • VSCode: Insiders 1.97.x

Steps to Reproduce

  1. Create a valid ~/.codex/config.toml with MCP servers, features, etc.
  2. Open VSCode with the Codex extension
  3. Close VSCode
  4. Reopen VSCode
  5. Check ~/.codex/config.toml - the entire content is duplicated (appended to itself)

Error Message

Invalid configuration; using defaults.
Error parsing config file /home/user/.codex/config.toml: TOML parse error at line 61, column 2 | [features] | ^^^^^^^^ duplicate key

Actual Behavior

Every VSCode restart appends the full config.toml content again, resulting in:

  • First restart: 2x content
  • Second restart: 3x content (or more)
  • File grows from ~1.5KB to 10KB+

Expected Behavior

config.toml should not be modified on VSCode startup. The extension should only read the config, not write/append to it.

Workaround

Setting the file to read-only (chmod 444 ~/.codex/config.toml) prevents the duplication but may block some features like "experimental features" updates.

Additional Context

  • The bug started appearing around extension version 0.5.60+
  • Happens consistently on every VSCode restart
  • Only affects VSCode extension, not the CLI directly

View original on GitHub ↗

3 Comments

etraut-openai contributor · 7 months ago

Thanks for the bug report. This is the first we've heard of this problem, so there must be something specific about your system or configuration that's triggering this behavior.

I wonder if it's related to something specific in your config file? Would you be willing to share the contents of your config file (with any personal details redacted, of course)?

And if you have any other clues about what might be different about your system or configuration that could help us repro this, that would be most appreciated.

swordfish444 contributor · 7 months ago

@etraut-openai A couple hypotheses / extra data points that might help narrow this down:

  • Is ~/.codex/config.toml a symlink (managed by dotfiles / chezmoi / stow / etc.)? If so, it might be hitting a path-resolution edge case on write.
  • - The behavior sounds exactly like an init/migration path doing an append instead of an overwrite (e.g. appendFile, or writeFile with flag: 'a'/a+). Might be worth grepping the extension for any config writes on startup.

If @albertodimas is willing, two quick repro clues to post (redacting secrets):

  • ls -l ~/.codex/config.toml + stat ~/.codex/config.toml
  • - The first ~30 lines of the config (or a minimal config that triggers it)

Startup logs from the extension would also help correlate which code path runs right before the append happens.

walterjj · 6 months ago

May be related: Subject: Config precedence warning misclassifies user config as project config

I noticed a confusing warning about config precedence/trusted projects.
The message says: “Project config.toml files are disabled in the following folders… 1. /home/walter/.codex … To load config.toml, add /home/walter as a trusted project…”.
The issue is that is the user config, not a project config. The warning appears to treat it as a project config because it’s found in the ancestor search path, which suggests the user config is being ignored (when it’s actually applied).
It would help to explicitly distinguish user vs project configs in the warning, or avoid recommending “trust” for the home directory when the path matches the user config location.