Proposal: thread-scoped pets and pet-mediated side discussions

Summary

Would the maintainers be open to a small, incremental pet feature direction that makes pets feel tied to individual Codex threads and side conversations?

The initial proposal is intentionally conservative:

• Allow a different terminal pet selection per chat/thread, with the existing global pet setting remaining the default.
• Let pet-driven commands open a side conversation so the pet can discuss a question without disrupting the main thread.
• Support a lightweight blue-team/red-team style prompt for pet-mediated review or debate.

Motivation

Pets are already a useful ambient UI element, but they currently feel global rather than connected to a specific chat. If a user works across multiple threads, it would be useful for each thread to have its own visual identity and for side conversations to inherit that identity.

This could also make existing side conversations feel more understandable: a /pets discuss ... or /pets debate ... flow can present the side thread as the current pet thinking through alternatives, risks, or opposing viewpoints, while keeping the main thread unchanged.

Proposed incremental scope

A first PR could avoid new model orchestration and reuse existing TUI concepts:

1. Store explicit per-thread pet selections, falling back to the global [tui].pet setting for threads without an override.
2. Restore the selected pet when switching or replaying threads.
3. Let side conversations inherit the parent thread pet unless they have their own override.
4. Add pet-mediated side prompts, for example:

• /pets discuss <prompt> for lightweight discussion.
• /pets debate <prompt> for blue-team/red-team style analysis.

This would make the feature mostly a TUI/state/prompting change rather than a new multi-agent architecture.

Non-goals for the first PR

• No autonomous background debate between unrelated chats.
• No persistent multi-agent orchestration changes.
• No desktop overlay interaction API changes in the first step.
• No custom pet manifest changes in the first step.

Those could be considered later if maintainers want to connect this to broader pet interaction APIs.

Related issues

This seems related but not identical to:

• #21657, which asks for custom interaction hooks and APIs for desktop pets.
• #22099, which discusses subagents and background task visibility.

This proposal is narrower: it starts with thread-scoped pet identity and pet-mediated side conversations in the TUI.

Prototype status

I have a small local prototype branch that implements the conservative TUI-first version described above. I am happy to split or adjust it based on maintainer feedback before opening a PR.