Add account groups with isolated CODEX_HOME support

[mouaadsk]

Summary

• Add managed account groups with isolated CODEX_HOME folders.
• Keep default mapped to the normal ~/.codex home and store named groups under ~/codex-auth/groups/<name>.
• Add group create/list/login/add/remove/import/switch/launch/path workflows.

Notes

• This PR is the minimal core group support. Follow-up enhancements such as grouped dashboard colors, copy/move, project launch memory, and per-group auto-switch manager are intentionally left for a stacked PR.
• Group names are restricted to shell-safe identifiers and paths are built through the existing cross-platform filesystem helpers.

Testing

• zig build run -- list
• zig build run -- group --help
• zig build test
• zig test src/main.zig -lc
• zig build -Dtarget=x86_64-linux-gnu
• zig build -Dtarget=x86_64-windows-gnu

[Loongphy]

This adds quite a bit of complexity, but I’m not sure I understand the value of the feature yet. Could you explain the intended use case? What problem does this solve in practice?

[mouaadsk]

The goal is being able to make accounts groups so you can separate each task/project with its groups of accounts.
The real benefit of it is when you want to work in parallel tasks and since now we have only one pool (default account), therefore the quota of each account will be drained rapidly and account switching happens often.
With this PR you can, make groups which have their CODEX_HOME separated from default, and when launching with this specific group CODEX_HOME it will use the accounts auths on the group.
NOTE : in the later PR I added the possibility of launching the codext with a special group (also it is being saved for each project), different colors of groups, etc.

[Loongphy]

Thanks for the explanation. I think the core use case here is already covered by the existing CODEX_HOME override: each command resolves one Codex home at startup, and list, import, switch, and remove all operate on that same root. So an isolated account pool can already be used without adding a separate group manager layer.

For example:

mkdir -p /tmp/codex-auth-work
CODEX_HOME=/tmp/codex-auth-work codex-auth import /path/to/auth-jsons
CODEX_HOME=/tmp/codex-auth-work codex-auth list
CODEX_HOME=/tmp/codex-auth-work codex-auth switch 02
CODEX_HOME=/tmp/codex-auth-work codex-auth remove old-account

And for another pool:

mkdir -p /tmp/codex-auth-personal
CODEX_HOME=/tmp/codex-auth-personal codex-auth import /path/to/other-auth-jsons
CODEX_HOME=/tmp/codex-auth-personal codex-auth list

That gives the same isolation model: separate auth.json, accounts/registry.json, account snapshots, and sessions under each CODEX_HOME. The only missing piece is convenience around naming/launching these homes, but I do not think that requires adding all of the group command surface to codex-auth itself.

[mouaadsk]

Yes I agree , as it was also explicit settings and the creation was manual and also movement of the accounts from a CODEX_HOME to another is not covered , I think it would be better to have a group manager.
Each time we need to switch we should explicitly change the CODEX_HOME.
So the previous Workflow would be : Add command for the CODEX_HOME so the codex-auth will use it , then you will read only the accounts in that codex home folder (the folder should be already created), you have no control with over the other CODEX_HOMEs as you would need to switch to them first.

New workflow, you launch codex-auth and it read all created codex_home folders existing with their accounts, you can create new one with it or remove one, controlling accounts by group (login, switching, enableing auto , etc) as it was covered before with manual switching.

NOTE : I prefer the new workflow as it is more cli and you can with one launching of the cli control all groups (CODEX_HOMEs) and less manual hustle and more global control.
At the end is for you to decide which direction to take.
NOTE : Personally I am using the group new manager locally, and the more helpful for me is the group <name_group> launch which launches codext with the group CODEX_HOME also it saves it locally, so next time codex-auth group launch will use the group saved for the project.