Skip to content

fix(cli): avoid locale import cycle during environment setup - #164

Draft
lx-1997 wants to merge 2 commits into
mainfrom
codex/fix-cli-env-locale-initialization
Draft

lx-1997 wants to merge 2 commits into
mainfrom
codex/fix-cli-env-locale-initialization

Conversation

@lx-1997

@lx-1997 lx-1997 commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

Importing the CLI one-shot module can crash with Cannot access SETUP_ZH before initialization when exactly one provider key is discovered from the environment and the locale is Chinese. Config initializes module defaults while cli-locale is still importing config, so building the auto-provider notice accesses a translation table in the circular import before it exists.

Use the existing dependency-independent uiText helper for this notice. Preserve both notice templates and the other locale behavior.

Validation:

  • New private-config, synthetic-key process regressions reproduce the Chinese failure before the change and pass for Chinese and English afterward. They also assert the notice language and that key values are not printed.
  • CLI environment config and locale/help specs passed.
  • The existing exhausted-stream JSON/Chinese/English process regression passed with the synthetic provider environment present.
  • npm run check and npm run smoke passed.

The test clears inherited Moss config file/path overrides as well as provider variables. It imports modules without making real provider calls; its fetch trap is not represented as a universal network sandbox. Full CI remains required before merge/release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant