Honor config.toml symlinks when creating or updating config

Resolved 💬 2 comments Opened Nov 14, 2025 by muyuanjin Closed Jan 19, 2026

What version of Codex is running?

codex-cli 0.58.0

What subscription do you have?

API

Which model were you using?

gpt-5-codex

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64 (Windows 11 host with WSL2 Ubuntu)

What issue are you seeing?

Since updating to 0.58.0 the CLI recreates ~/.codex/config.toml on startup/update and silently replaces my existing symlink with a regular file containing default config. This breaks my setup where the real config lives on the Windows side and is symlinked into WSL.

What steps can reproduce the bug?

  1. On 0.57.x (or any build prior to 0.58.0) create a config on Windows and symlink it into WSL.
  2. Upgrade Codex CLI to 0.58.0. Launch codex.
  3. Inspect ls -l ~/.codex/config.toml. The symlink has been replaced by a regular file containing the new default config.

What is the expected behavior?

The upgrade/startup process should respect an existing symlink (or at least prompt before removing it) so shared configs remain usable after upgrades.

Additional information

auth.json symlinks survive the upgrade; only config.toml is rewritten. The new file always contains a [notice] block with hide_gpt5_1_migration_prompt = true. Please avoid unlinking when the target is already a symlink.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗