fix(migration): map default_yolo to default_permission_mode instead of dead yolo field#124
Conversation
…f dead yolo field The kimi-cli config key `default_yolo` was being migrated to `yolo` in kimi-code config.toml, but `yolo` is a dead field that no code reads. The real config key for yolo mode is `default_permission_mode = "yolo"`.
🦋 Changeset detectedLatest commit: f1d0de0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1d0de07aa
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // kimi-cli's `default_yolo` is kimi-code's `yolo`. | ||
| if (v === true) migratedTop['yolo'] = true; | ||
| // kimi-cli's `default_yolo` maps to kimi-code's `default_permission_mode`. | ||
| if (v === true) migratedTop['default_permission_mode'] = 'yolo'; |
There was a problem hiding this comment.
When the target config already has defaultPermissionMode = "manual" (which parseConfigString accepts because transformTomlData leaves camelCase keys as defaultPermissionMode), this adds a separate default_permission_mode = "yolo" instead of recording a conflict. After migration the transformed config contains both keys and the later snake_case entry wins, so a user-modified target config can be silently changed to yolo despite mergeConfig's “target value is never overwritten” policy. Please normalize/check the camelCase target key before adding this migrated value.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
The config migration step fires at most once — on first launch when switching from kimi-cli to kimi-code. At that point the target config.toml is either missing, a default stub, or freshly generated — the user has not had a chance to manually edit it with camelCase keys. This edge case is not reachable in practice.
1 participant
Related Issue
Resolve #123
Problem
The kimi-cli → kimi-code config migration step maps
default_yolo = truetoyolo = truein config.toml, butyolois a dead field — no code in kimi-code reads it. Users who migrated from kimi-cli with yolo enabled end up without yolo mode after migration.What changed
Changed the migration mapping from
migratedTop["yolo"] = truetomigratedTop["default_permission_mode"] = "yolo", which is the correct config key recognized bycore-impl.tsfor enabling yolo auto-approval mode.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.