Proposal: mobile companion app path for T3 Code

[hogeheer499-commits]

Summary

I built a small unofficial mobile companion for T3 Code and would like to discuss whether any part of this should become an upstream-supported path, docs link, or set of smaller reliability improvements.

Repo: https://github.com/JSvandijk/t3code-mobile

The goal is not to turn T3 Code into a different product. The project is intentionally narrow: browserless access to an existing T3 Code session on Android, plus an optional PWA/proxy path for installable mobile usage.

What it currently does

• Android WebView wrapper without browser chrome
• One-time base URL setup with reconnect support
• Accepts full T3 pairing links, but stores only the base server URL
• Keeps navigation scoped to the configured T3 host instead of becoming a generic browser
• Copyable diagnostics for HTTP, SSL, and network failures
• Inline image upload support that is reinjected after SPA navigation
• Optional HTTPS/PWA proxy with GET /__t3mobile/health, upstream latency reporting, and smoke coverage
• Local WebView harness modes for HTTP, bad-cert HTTPS, and redirect behavior

Current evidence

From a clean local checkout after npm install:

• npm test passed
• JS syntax checks passed
• ESLint passed
• manifest.json parse check passed
• release checks passed for version 1.1.0
• HTML unit tests passed: 18/18
• proxy smoke test passed

The repo also includes docs around upstream fit and scope: https://github.com/JSvandijk/t3code-mobile/blob/main/docs/UPSTREAM-FIT.md

Why I am opening an issue instead of a large PR

This is product scope, not a tiny bug fix. The contributing guide is clear that large feature PRs are unlikely to be accepted and that non-trivial changes should start with an issue.

A few possible upstream-friendly paths:

• Keep the mobile app external, but document the remote-access expectations that companion clients should rely on.
• Extract small reliability/diagnostics improvements from the app experience into T3 Code itself.
• Add a short community/experimental companion note if maintainers want users to know this exists.
• Do nothing upstream for now, but use the app as real-world feedback for LAN/tailnet/mobile connection reliability.

Questions

• Is an unofficial mobile companion something the project would want to acknowledge at all?
• If yes, would maintainers prefer a docs-only PR, smaller remote-access reliability PRs, or keeping it fully external?
• Are there mobile/client behaviors that would be useful for T3 Code to support more formally, such as stable diagnostics or health endpoints?

I am happy to keep any follow-up small and evidence-backed rather than submitting a large app import.

[hogeheer499-commits]

Small status update after checking the companion repo again on May 5, 2026.

Current t3code-mobile repo state:

• latest release remains v1.1.0
• npm test passes from a fresh local checkout after npm install
• JS syntax checks pass
• ESLint passes on current main
• manifest.json check passes
• release checks pass for version 1.1.0
• HTML tests pass: 18/18
• proxy smoke test passes

I also checked the open maintenance PRs. Dependabot #18 bumps ESLint to 10 but fails CI because ESLint 10 requires flat config. I opened JSvandijk/t3code-mobile#19 with the same ESLint 10 bump plus eslint.config.cjs; local npm test passes there too, with 0 lint errors and the existing 2 server.js warnings.

This does not change the ask here: I am still treating the mobile companion as a scope/proposal discussion first, not as a large app import PR.

[hogeheer499-commits]

Follow-up: I also opened JSvandijk/t3code-mobile#20 to update the linked docs/UPSTREAM-FIT.md page itself with the May 5 validation data and links back to this upstream discussion.

That keeps the referenced document current for anyone reviewing this issue later, instead of relying only on comments here.

[JSvandijk]

Maintenance follow-up from May 5, 2026.

I refreshed the linked companion repo so this proposal points at current information instead of a stale two-week-old state:

• merged Update ESLint 10 config JSvandijk/t3code-mobile#19 for the ESLint 10 flat-config migration, Node runtime alignment, and current CI/release Node setup
• merged Refresh upstream fit validation JSvandijk/t3code-mobile#20 to update docs/UPSTREAM-FIT.md with current validation data and this upstream discussion link
• closed Bump eslint from 8.57.1 to 10.2.1 JSvandijk/t3code-mobile#18 as superseded by Track per-thread terminal running state in UI and store #19
• rechecked the five open maintenance issues in the companion repo and updated each with current status rather than leaving stale triage labels

Current companion repo state after those merges:

• latest main: JSvandijk/t3code-mobile@27208c2
• no open PRs
• GitHub CI passed for Track per-thread terminal running state in UI and store #19 and Add deterministic dev port runner for multi-instance local workflows #20, including node-checks and android-build
• local npm ci passed
• local npm test passed with ESLint 10 and no lint warnings
• local cmd /c build-apk.bat passed and produced a dev-signed APK

The linked upstream-fit doc is now current again:
https://github.com/JSvandijk/t3code-mobile/blob/main/docs/UPSTREAM-FIT.md

The proposal here is still intentionally narrow: keep the mobile companion external unless maintainers want docs or small reliability improvements upstreamed.

[JSvandijk]

Additional maintenance follow-up from May 5, 2026.

I made two more maintenance improvements in the linked companion repo to reduce the chance that this proposal points at vague or under-proven claims:

• merged Improve proxy guidance and upload assertions JSvandijk/t3code-mobile#21 with a concrete proxy deployment checklist for trusted-network use vs unsafe public exposure
• added DOM-level automated assertions for the proxy upload-button path: preferred placement, hidden image file input creation, paste-event dispatch, and fallback placement
• added Android WebView source-marker checks for the critical upload injection path
• updated ESLint from 10.2.1 to 10.3.0
• closed Add automated assertion coverage for the upload-button path JSvandijk/t3code-mobile#15 and terminal links #17 as fixed by Show pulsing terminal activity icon in thread sidebar #21

Current companion repo state:

• latest main: JSvandijk/t3code-mobile@cc005c2
• no open PRs
• GitHub CI passed on main, including node-checks and android-build
• local npm test passed
• local npm outdated reported no outdated packages
• local cmd /c build-apk.bat passed and produced a dev-signed APK

Remaining open gaps are intentionally still tracked instead of overstated: runtime recapture for invalid-cert UX, release signing continuity, and longer-term DOM selector hardening.

[juliusmarminge]

T3 Code now has an official mobile application with native connection/pairing and mobile thread, file, and terminal surfaces. That supersedes the proposed unofficial companion path.

This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.