Motivation
Oh My Portal is primarily about using CLI agents from a phone, but a native terminal such as Termux is not necessarily the best interface for long-running agent work.
Termux is excellent as a real shell, but mobile agent UX exposes several limitations that a purpose-built web frontend can potentially avoid. agent-frontend should explicitly design around those advantages rather than merely reproducing a terminal in the browser.
This complements #11, which covers reconnect-safe sessions and scroll restoration in detail.
Where a web frontend can be better than Termux
1. Touch can be a first-class input
A terminal fundamentally exposes character, key, mouse, and escape-sequence semantics. Touch is translated into those abstractions and TUI applications may not understand it consistently.
A web frontend owns the DOM and can expose actual mobile controls:
- tappable messages, buttons, tool calls, models, sessions, and menus
- reliable touch scrolling without depending on terminal mouse mode
- large mobile-friendly hit targets
- swipe/long-press gestures where useful
- direct selection/copy actions per message or code block
This matters especially for agents whose TUI was primarily designed around a keyboard and desktop terminal.
2. Better soft-keyboard behavior
Terminals interact awkwardly with Android IMEs because composition, Unicode input, resize, and special keys all pass through terminal abstractions.
A browser composer can use ordinary text input semantics and can therefore handle:
- IME composition directly
- Korean/CJK composition without waiting for a terminal keystroke boundary
- multiline editing before submission
- mobile autocorrect / clipboard / selection
- explicit buttons for Enter, Escape, Ctrl-like actions when needed
The goal is not to emulate every terminal key. It is to avoid requiring terminal keys for normal agent conversation.
3. UI state does not have to equal terminal state
A TUI frequently redraws the entire viewport. Scrollback and the application's current screen are therefore tightly coupled to PTY behavior.
A semantic frontend can keep durable UI concepts independently:
- transcript
- message IDs
- tool calls
- running jobs
- session list
- draft input
- scroll anchor
- follow-tail state
This is what makes the reconnect model in #11 possible without treating a terminal screen as the source of truth.
4. Better recovery after disconnect, backgrounding, and resize
Neither Termux nor a mobile browser can guarantee that the client stays alive forever. Android may suspend processes, the network may change, and browsers may discard pages.
The difference is that a frontend can make reconnection part of the application protocol:
agent session != terminal connection != browser connection
A new client can reattach by session_id, replay missed events, restore the transcript, preserve the reading position, and continue a draft. See #11.
5. Structured agent output is more useful than ANSI output
A terminal sees rendered text. agent-frontend can understand the actual agent event model.
That enables richer mobile UI for:
- code blocks with copy actions
- tool calls and tool results
- approvals / confirmations
- subagent progress
- token/cost information
- model switching
- files and artifacts
- collapsible long outputs
- notifications and completion state
These features are much harder to layer reliably on top of terminal escape sequences.
6. View state can survive process death
A web frontend can persist lightweight client state such as the active session, draft, scroll anchor, and last event sequence independently from the host-side agent.
This makes "close the phone and come back later" a normal workflow instead of a terminal restoration problem.
7. The UI can adapt to phone form factors
A TUI has to fit a rectangular character grid. A web frontend can change layout based on screen size and orientation:
- bottom composer on phones
- session drawer instead of sidebar
- collapsible tool details
- responsive code views
- full-screen dialogs for complex actions
This should be especially valuable on foldables and tablets where available width changes dynamically.
What the web frontend does not replace
This should not become an argument for removing agent-terminal or Termux.
A real terminal remains better for:
- arbitrary shell commands
- editors and TUIs
- SSH administration
- debugging frontend/bridge failures
- workflows the adapter protocol does not expose
The useful split is:
agent-frontend → primary mobile UX for agent interaction
agent-terminal → full shell, recovery, debugging, unsupported workflows
Termux → native local terminal when direct device-side shell access is desired
In other words, agent-frontend should not try to become a better terminal emulator. Its advantage comes from not being a terminal at all.
Design direction
Treat mobile web as a semantic client attached to a durable host-side agent session.
When deciding between exposing another terminal/TUI behavior and adding a structured frontend primitive, prefer the structured primitive when the underlying agent protocol exposes enough information to support it.
This would make Oh My Portal useful not merely as "Termux/ttyd over Portal", but as a genuinely better interface for long-running AI coding sessions on phones.
Motivation
Oh My Portal is primarily about using CLI agents from a phone, but a native terminal such as Termux is not necessarily the best interface for long-running agent work.
Termux is excellent as a real shell, but mobile agent UX exposes several limitations that a purpose-built web frontend can potentially avoid.
agent-frontendshould explicitly design around those advantages rather than merely reproducing a terminal in the browser.This complements #11, which covers reconnect-safe sessions and scroll restoration in detail.
Where a web frontend can be better than Termux
1. Touch can be a first-class input
A terminal fundamentally exposes character, key, mouse, and escape-sequence semantics. Touch is translated into those abstractions and TUI applications may not understand it consistently.
A web frontend owns the DOM and can expose actual mobile controls:
This matters especially for agents whose TUI was primarily designed around a keyboard and desktop terminal.
2. Better soft-keyboard behavior
Terminals interact awkwardly with Android IMEs because composition, Unicode input, resize, and special keys all pass through terminal abstractions.
A browser composer can use ordinary text input semantics and can therefore handle:
The goal is not to emulate every terminal key. It is to avoid requiring terminal keys for normal agent conversation.
3. UI state does not have to equal terminal state
A TUI frequently redraws the entire viewport. Scrollback and the application's current screen are therefore tightly coupled to PTY behavior.
A semantic frontend can keep durable UI concepts independently:
This is what makes the reconnect model in #11 possible without treating a terminal screen as the source of truth.
4. Better recovery after disconnect, backgrounding, and resize
Neither Termux nor a mobile browser can guarantee that the client stays alive forever. Android may suspend processes, the network may change, and browsers may discard pages.
The difference is that a frontend can make reconnection part of the application protocol:
A new client can reattach by
session_id, replay missed events, restore the transcript, preserve the reading position, and continue a draft. See #11.5. Structured agent output is more useful than ANSI output
A terminal sees rendered text.
agent-frontendcan understand the actual agent event model.That enables richer mobile UI for:
These features are much harder to layer reliably on top of terminal escape sequences.
6. View state can survive process death
A web frontend can persist lightweight client state such as the active session, draft, scroll anchor, and last event sequence independently from the host-side agent.
This makes "close the phone and come back later" a normal workflow instead of a terminal restoration problem.
7. The UI can adapt to phone form factors
A TUI has to fit a rectangular character grid. A web frontend can change layout based on screen size and orientation:
This should be especially valuable on foldables and tablets where available width changes dynamically.
What the web frontend does not replace
This should not become an argument for removing
agent-terminalor Termux.A real terminal remains better for:
The useful split is:
In other words,
agent-frontendshould not try to become a better terminal emulator. Its advantage comes from not being a terminal at all.Design direction
Treat mobile web as a semantic client attached to a durable host-side agent session.
When deciding between exposing another terminal/TUI behavior and adding a structured frontend primitive, prefer the structured primitive when the underlying agent protocol exposes enough information to support it.
This would make Oh My Portal useful not merely as "Termux/ttyd over Portal", but as a genuinely better interface for long-running AI coding sessions on phones.