[Discussion]: Does Chat still need same-session TUI switching? #17424

Summary

While there's a lot I love about Orca, compared to other ADEs I've tried the Chat GUI experience in Orca is quite poor -- frequent hangs, can't select model/provider features, etc. Digging into why it might be different, I came across some comments suggesting that it is essential to build the chat GUI in a way that allows instant switching back to the terminal (TUI) and back during a conversation. I suspect this requirement may be what's holding back Orca's chat GUI implementation.

Details

In the main Chat UI issue, it was mentioned that ACP looked promising, but not being able to switch from TUI to GUI was considered a "deal breaker":

#3099 (comment)

I think that requirement may be worth revisiting.

I get the appeal. The native TUI gives you every new and provider-specific feature, and it is a great escape hatch when Chat cannot handle a prompt, approval, command, or other state. Being able to switch views without losing the conversation would be genuinely useful.

At the same time, it seems like Orca may be tying together three different goals:

1. Preserve the conversation and its context.
2. Keep a terminal/native-harness escape hatch available.
3. Let the same active session move back and forth between Chat and TUI like they are simply two views of one process.

The first two feel important. I'm not sure the third needs to be a hard requirement for a good Chat experience.

Structured Chat and a native TUI can be separate session controllers. Making that handoff seamless means dealing with ownership, process exit, session identity, history reconciliation, and recovery if the switch fails halfway through. Orca's handoff work shows how much machinery this can require:

• feat: toggle structured sessions between chat and TUI #13790
• Adopt Codex terminal sessions into structured native chat #15411

The harnesses do not seem to support this consistently either. Claude supports resuming saved sessions, but not a documented live SDK ↔ TUI handoff. Codex now has a shared app-server model, but that is a different setup from handing a conversation between two independently launched controllers.

What if the principle were loosened to something like:

Preserve conversation continuity where possible, and always provide a clear terminal or native-harness escape hatch—but don't make instant, bidirectional TUI handoff a prerequisite for a first-class Chat UI.

Where a provider supports a shared runtime, perhaps the TUI could attach to it. Otherwise, an explicit Stop Chat and resume in native CLI action might be enough. A normal workspace terminal could also remain available without necessarily controlling the active Chat session.

The newer structured Codex work already seems to separate these concerns: PR #16729 explicitly leaves out one-click terminal ↔ native switching, while terminal-session adoption remains separate in PR #15411.

• feat(native-chat): Codex structured native chat restructure #16729
• Adopt Codex terminal sessions into structured native chat #15411

I'd be interested in the maintainers' thoughts:

• What workflow originally made same-session switching a "deal breaker"?
• Is the important part keeping the exact provider session ID, preserving context, or simply having a reliable fallback when chat UI can't handle something?
• Would provider-specific behavior—or an explicit stop-and-resume handoff—cover the important use cases without making live switching a requirement for Chat?

P.S. I really do love Orca. Of the ADEs I've tried, it has the best overall mix of workspace management, orchestration, polish, and day-to-day features for how I work. Chat reliability is the one big exception, and unfortunately it is the main thing driving me toward other tools.