Codex Desktop writes custom pet ID into `tui.model_availability_nux`, breaking all task creation

Summary

After creating and installing a custom Pet, Codex Desktop wrote the pet selection into the wrong TOML table:

[tui.model_availability_nux]
"gpt-5.5" = 4
selected-avatar-id = "custom:teddy"

Because values in tui.model_availability_nux are expected to be unsigned integers, every subsequent prompt/task failed during config deserialization.

Error

Error creating task

invalid configuration: invalid type: string "custom:teddy", expected u32
in `tui.model_availability_nux`

Environment

• Codex Desktop version: 26.707.61608
• OS: Windows
• Custom pet name/ID: Teddy / custom:teddy

Steps to reproduce

1. Use the Hatch Pet feature to create a pet from uploaded JPG photos.
2. The generated package includes a custom pet definition such as package/teddy/pet.json.
3. The custom pet does not initially appear under Settings → Pets.
4. Ask Codex to install the custom character and change the current pet to it.
5. Codex reports: “Teddy is now installed and selected as your Codex pet.”
6. Restart/select Teddy in Settings.
7. Submit any prompt.
8. Every task fails with the configuration error above.

Actual behavior

The selected custom avatar ID is persisted under:

[tui.model_availability_nux]
selected-avatar-id = "custom:teddy"

This makes the entire Codex configuration invalid because that table expects u32 values.

Expected behavior

• Custom pet selection should be persisted in the appropriate Desktop/avatar state location, not inside tui.model_availability_nux.
• Selecting or installing a custom pet should never make the global config unreadable or prevent task creation.
• Ideally, config parsing should ignore or migrate misplaced/unknown UI keys instead of blocking all tasks.

Workaround confirmed

Closing Codex and deleting the invalid selected-avatar-id = "custom:teddy" entry (or deleting the entire [tui.model_availability_nux] section) from %USERPROFILE%\.codex\config.toml restores task creation immediately.

The custom pet assets themselves were not deleted, so this appears to be a persistence/config-placement bug rather than a malformed pet asset issue.

Additional notes

This was produced through the normal conversational Pet creation/install workflow rather than by manually editing config.toml. Screenshots of the Hatch Pet conversation, installation confirmation, and the error are available if needed.