[Feature]: Oh My Pi support

[maximhar]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

I've been growing progressively annoyed with the piece of crap the Codex harness is becoming (it's gotten bloated and extremely inefficient), but I've grown very fond of having a nice shiny GUI. So when I tried to go back to Oh My Pi (probably the best overall coding harness in my opinion) it was really difficult to get adjusted back to the terminal.

Then I found out about t3code but imagine my disappointment when I found out that the only non-crap GPT-capable harness it supports is OpenCode. And OpenCode, albeit less crap than Codex and Claude Code, is still not great. Since OMP already has ACP support, I figure it shouldn't be too difficult to add it in t3code. I promise to become a loyal t3 fan if you do that!

Proposed solution

native OMP support:

Why this matters

It would instantly give Oh My Pi a very very nice GUI

Smallest useful scope

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[Gabriel-Hiss]

+1

[wosnxn123]

+1

[ErebusBat]

I will say that if/when this is done... please please please make sure that it supports omp profiles natively

[xHeaven]

+1

[duducpp]

+1

[EndorFlem]

+ 1

[LightningSB]

isn't this PR implementing exactly that?

#3847

[Gabriel-Hiss]

well it was...

[RayBytes]

+1

[nezzard]

+1

[riccardo-algorime]

+1

[rynfar]

• 1

[phoenix-error]

+1

[rblaine95]

Please don't just comment "+1" as it just results in spam and doesn't contribute anything to the discussion.
Rather react with a 👍 to the OP.

[anstaendig]

I would appreciate official OhMyPi support here; it's a great harness. I've got it running locally in T3Code, but haven't tested it thoroughly; it's definitely doable.

[watzon]

I have a working OMP integration against current main and OMP 17.4.0. I am holding the PR until the maintainers agree on the scope.

Proposed scope

• Add OMP as a built-in provider with binary path, environment, launch arguments, and multiple provider instances.
• Discover models with omp models --json --no-extensions. Keep the full OMP selector for execution and show the upstream provider in the model picker. Duplicate names then appear as Oh My Pi · Moonshot, Oh My Pi · OpenRouter, and similar labels.
• Start, resume, cancel, and supervise ACP sessions. Forward images and map the T3 permission modes to OMP approval modes.
• Use OMP for thread titles, commit messages, branch names, and PR text.
• Support named OMP profiles through --profile <name> in Launch arguments. Model discovery uses the same profile through OMP_PROFILE, and ACP sessions receive the profile argument.
• Support the web, desktop, and mobile clients. Include focused server, contract, web, and mobile tests.

The implementation keeps OMP behavior in a separate adapter. I reviewed the earlier attempt in #3847. That PR changed the shared Cursor ACP path and closed with unresolved review findings. The new approach makes only small additions to the shared ACP session runtime and does not refactor the Cursor adapter. It never replaces a requested model with a fallback model.

Current model-picker prototype:

OMP 17.4.0 limits

• OMP ACP does not expose the Plan mode lifecycle or provider-history rollback. T3 hides Plan mode and reports rollback as unsupported.
• A supervised shell command or destructive edit can show two approval forms. OMP applies both an ACP client gate and its native approval gate.
• Health checks do not load extensions. Users can add extension-only selectors through Custom models, and the normal OMP session validates them.

I would like maintainer input on three points before I open the PR:

1. Is full provider parity acceptable as one focused provider PR, or do you want a smaller first slice?
2. Is profile selection through Launch arguments acceptable, or should OMP have a first-class profile field?
3. Is Oh My Pi · <upstream provider> the preferred model label?

I briefly opened #7763 before this discussion step, then closed it. The implementation remains ready in the fork while this discussion is open.