Improve mobile terminal reliability and session tooling

[Lint111]

Summary

• Add opt-in mobile terminal navigation with swipe/up/down/Enter controls, safer edge-positioned Tab/Esc actions, dialog coexistence, and touch feedback.
• Make mobile input durable across tab changes and browser lifecycle events, with multiline paste, delete/local-echo synchronization, mirrored input, and keyboard-aware layout fixes.
• Add lossless bounded terminal streaming, compressed incremental transport, warm session caches, restart recovery, and immutable frame handoffs that hide Codex history replay during tab and keyboard transitions.
• Add repository/worktree diff and response inspection views, inline case edit/delete actions, preserved session labels/work paths, and related mobile UX improvements.
• Reduce hook noise while preserving background-command wakeups and integrate the branch with upstream web tabs, themes, and repository conventions.

Merge notes

Merged origin/master at 57b6be1. Conflicts in CLAUDE.md and styles.css retain upstream structure/theme work and document the combined mobile/webview invariants.

Validation

• Lockfile, formatting, public assets, frontend syntax, typecheck, lint, and production build passed.
• Mobile browser suites: 78 keyboard tests and 17 navigation/file-viewer tests passed.
• CI-equivalent suite: 197 files passed, 1 skipped; 3,926 tests passed, 12 skipped.
• Live Playwright capture verified immutable Claude-to-Codex and Codex keyboard open/close transitions against a 26 MB terminal history.

[Ark0N]

Hi Lior, thank you for all of this, and I owe you a straight answer rather than more silence. I'm closing this PR and the sixteen others, and I want to explain properly, because the reason is not that the work is worthless.

The volume is the core problem.

There are seventeen open PRs from you, sixteen of them opened on 2026-07-29, totaling roughly 42,000 added lines. This one alone is +22,581 / -2,312 across 100 files. That is more change than the project took in over its previous several releases combined.

It may help to know what reviewing a PR here actually costs me. Earlier today I merged three small ones (#203, #214, #215, together about 800 lines). For those I merged all three into a scratch worktree to check they did not conflict, ran the full 3,971-test suite on the combined result, copied each contributor's new tests onto unmodified master to confirm they genuinely failed there, and ran the merged build side by side with production against my real transcript tree to confirm the behavior change was the claimed one. That is the bar, and those three took most of a working session.

At that standard, 42,000 lines is months of full-time review. I cannot give your PRs that, and merging them at a lower standard is worse than not merging them, because I am the one who carries whatever goes in.

The split did not make them independent.

I appreciate that you broke this up rather than leaving one giant PR, and that was the right instinct. But the slices land on the same hot files: nine of them touch app.js, eight touch terminal-ui.js, and four each touch session.ts and session-routes.ts. Five already conflict with master. So merging any one invalidates the diffs of the others, and none can really be evaluated on its own. The split multiplied the surface without decoupling it.

Separately, none of the seventeen have CI results, so I have no signal that any of them typecheck, lint, or pass the suite in this repo's environment.

Where they land matters.

The bulk of this work concentrates on input delivery, session identity, terminal replay, and file serving. Those are the parts of Codeman with the most hard-won invariants, and they are documented at length in docs/architecture-invariants.md precisely because the failure modes are subtle and expensive. This project has already shipped an auth-bypass class of bug (DNS rebinding plus text/plain CSRF, fixed in 0.9.5), and the multi-user PR needed an exhaustive review pass that turned up fifteen cross-user scoping holes before it was safe to merge. The file viewer in #183 would be a fourth independent file-serving surface, each of the existing three having its own confinement rules and its own caveats about what it does and does not inherit from the others.

I want to be fair to you here: I looked at #183's path handling and it is not careless. It realpaths both sides, rejects null bytes and absolute paths, and escapes diff rows before rendering. That is better than I expected. But "not obviously wrong on the paths I spot-checked" is a long way from the confidence I need before adding another surface that reads arbitrary repository files, and getting to that confidence is exactly the review time I do not have at this volume.

What I'm asking for going forward.

Please keep no more than three open PRs at a time. Beyond that it stops being a queue and starts being a backlog that makes the whole project harder to navigate, for me and for anyone else looking at the issue tracker.

What works well here:

• One behavior change per PR, as small as it can be while still standing alone.
• A concrete statement of the bug: what breaks, on what device or configuration, and how to see it.
• A test that fails on master and passes with the change. If you say that in the description, I will check it, and it is the single fastest way to earn trust in a diff.
• Merge cleanly against current master.

#214 and #215, which I merged today, are good models. Both were small, both named the exact bug, both shipped tests that genuinely failed before the fix, and #215 in particular walked through a revision it had gone through after review. That earned a fast, confident merge.

This is not a door closing on you. You clearly use Codeman heavily on mobile and you are hitting real friction that I would like fixed. If you pick the single mobile bug that annoys you most, open one focused PR for it, and let it get merged before opening the next, I will review it properly and promptly. I would rather land ten good small PRs from you over the next few months than leave seventeen sitting open that neither of us can move.

Thanks again for the effort, and sorry it took me this long to come back to you on it.

[Ark0N]

One thing I want to make unmistakable, because rereading my message above I think it lands more like a full stop than I meant it to.

Please do bring these back. Not all seventeen, but the ones that fix something real. I closed them because I could not review forty-two thousand lines at once, not because I decided the underlying work was wrong. Several of these are pointed at genuine friction, and I would rather have those fixes than not.

The only thing I am asking you to change is the rate. Three open at a time, maximum. Reopen the one you think matters most, rebased on current master, standing on its own, and once it lands, open the next. If you would rather I help pick, say the word and I will look through the list and tell you which two or three I would take first, so you are not guessing at what I will accept.

Sixteen at once meant none of them got looked at. Three at a time means all of them eventually do.

[Lint111]

Thanks for taking the time to write that out — the detail on what review actually costs you was the part that landed, and the rate limit is fair. I'd like to take you up on the offer to pick.

I have zero PRs open right now, so there's room for three whenever you want to point me at them.

Two things from your review are already fixed on my branch, in case they change what's worth reviving:

• POST /api/system/shutdown (feat(server): add authenticated instance shutdown #182) now returns 403 unless CODEMAN_PASSWORD is set when multi-user mode is off, checked before the requireAdmin call — so the ambient-admin no-op you found is closed rather than papered over.
• The mobile header guard is back to MOBILE_VISIBLE_ALLOWLIST = new Set<string>([]) with btn-file-viewer restored to KNOWN_PHONE_HIDDEN. I shouldn't have edited the guard instead of satisfying it.

The keyboard-focus blocker you reduced in _classifyMobileTerminalTap() I still owe you a proper fix and a test for — your point that the current mobile tests assert routing decisions while the user-visible outcome is broken is exactly right, so whatever I send will assert document.activeElement === terminal.textarea after a tap.

Of the closed ones, my instinct is that these three are the most self-contained, but I'd rather have your read than mine:

• fix(mobile): route terminal taps without opening the keyboard #186fix(mobile): route terminal taps without opening the keyboard — closest to the blocker you found, so it should probably come with the focus fix rather than separately.
• fix(terminal): drain deferred output without a wake event #190fix(terminal): drain deferred output without a wake event
• fix(mobile): coalesce keyboard viewport settling #194fix(mobile): coalesce keyboard viewport settling

If you'd rather name a different two or three, I'll work from your list instead. Either way I'll send them one at a time, rebased on current master, each with a test that fails without the change, and wait for one to land before opening the next.

[Ark0N]

Thanks for coming back with this, and for the two fixes you already made unprompted. Moving the shutdown check ahead of requireAdmin and putting the header guard back to an empty allowlist are both the right call.

I went through the closed list with current master open next to it, and your three are the same three I would have picked. What I can add is an order, because master has moved a lot under some of them and barely at all under others.

#194 first. It only touches mobile-handlers.js, and that file has not changed since you branched, so it should rebase clean. Smallest diff, quickest review.

#190 second. I checked its premise before agreeing: master is on @xterm/xterm 6 now, so passing the DEC 2026 markers through instead of parsing them client-side (and sometimes discarding partial blocks) is correct. Keep the terminal-anti-flicker.md rewrite in the same PR, the doc really does describe the old parser. One caution: terminal-ui.js has taken about a dozen commits since July 29, mostly the #205 scrollback and wheel work. That churn sits in the scroll-routing paths rather than the write/flush path, so the rebase should be mechanical, but read those commits before assuming.

#186 last, folded together with the keyboard-focus fix. This is the one I want most, and also the one where master has changed the most underneath. Since you branched, wheel and touch scrolling on mobile now forward to the CLI transcript for claude/codex sessions (part of the #205 work), so your tap classification has to coexist with a touch path that did not exist in July. The document.activeElement === terminal.textarea assertion you described is exactly the test I want on it.

One timing note: I have #227 open right now, round 2 of the scrollback fix, and it touches terminal-ui.js again. #194 does not care, so send that whenever you like. For #190 and #186 it is worth waiting until #227 lands so you only rebase once.

#182 can take a slot after these three. The 403-before-requireAdmin version you describe sounds like the right fix, and I would rather review it fresh than against my memory of the old diff.

One at a time with each landing before the next opens works for me, and so does having all three open at once, since only #190 and #186 share a file. Your call.

And thank you for the work so far. The closure was about review capacity, never about the list; these three are pointed at real friction, and I want them in.