Phone-native AI Coding Harness
The agent harness runs on the phone. Models can be remote; the coding loop, files, previews, runtime routing, and shipping controls stay in MobileCode.
不是远程 IDE 的手机壳，而是真正把 agent loop、工具状态、文件、预览和发布控制面放到手机本机的 MobileCode。

Watch 15s Short · Watch 9:16 Promo Video · README Motion Cover · HTML Principle Video · Download v0.1.68 apps · GitHub Pages Demo

Demo Lab · 2048 Demo · GitHub Test · Dual app build · Download app builds · Release QA

_{15-second Remotion teaser with voiceover. Full explainer covers demand, pain, RuntimeProvider, and GitHub-first shipping.}

MobileCode is packaged as a phone-native coding harness: a small mobile companion for writing, previewing, running agent tasks, and shipping artifacts from the same handheld workspace.

_{If your Markdown viewer does not embed video, open mobilecode-product-walkthrough.mp4.}

MobileCode 的第一性原理很简单：手机端不适合塞一个完整桌面编译环境，但非常适合成为 AI coding 的本机 harness。

它不是 Codex Remote、Claude Remote 或云端 IDE 的移动端外壳。模型可以来自云端 provider，但对话、工具编排、运行时选择、文件落盘、WebView 预览、GitHub 发布和恢复提示都在手机 App 内闭环。

它把最重的部分交给外部平台，把最贴近用户的部分留在手机上：

PhoneWorld 的最新研究把 phone-use agent 的瓶颈从“模型是否会点手机”推进到“谁能规模化提供可控环境、任务、验证器、轨迹和训练/评测 harness”。这不是对 MobileCode 的直接背书，但它清晰说明了一个方向：手机 Agent 的下一阶段核心资产是可执行、可复现、可验证的 harness。

MobileCode 选择从 AI coding 切入同一条趋势：模型可以远程，重构建可以交给 GitHub Actions，但会话、工具轨迹、文件、HTML/Markdown 预览、运行时路由、GitHub 发布、构建 artifact 和结果证据需要在手机端形成闭环。

• Paper: PhoneWorld: Scaling Phone-Use Agent Environments
• Local PDF: docs/research/phoneworld-scaling-phone-use-agent-environments-2605.29486.pdf
• MobileCode analysis: PhoneWorld 与 Mobile Harness 时代
• Long-term roadmp: Mobile Harness 长期路线图
• ICLR draft: PDF · TeX
• Anonymous supplement boundary: include/exclude and redaction gate
• Current anonymous supplement: paper/iclr-mobile-harness/build/mobile-harness-anonymous-supplement.zip (staged file count and byte size are emitted by the supplement script)
• Benchmark seed: MobileHarnessBench
• v1 task bank: 200 MobileHarnessBench candidate tasks
• v2 task bank: 1000 MobileHarnessBench candidate tasks
• v2 quality audit: machine audit report
• Verifier contracts: machine-readable catalog · coverage readiness
• Baseline protocol: comparison readiness
• Baseline run contract: result schema readiness
• Baseline scaffold: not-run scaffold manifest
• Baseline T0 dry run: not-counted dry-run manifest
• Baseline pilot pack: prompt and evidence templates
• Baseline pilot readiness: non-counted readiness gate
• Core claim readiness: positioning claim boundary
• Evidence maturity: claim maturity matrix
• Evaluation protocol readiness: E1-E5 machine-checkable protocol
• Method presentation readiness: visuals, algorithms, modules and formulas gate
• Bibliography readiness: verified related-work metadata
• Threats to validity: review risk matrix
• Page-limit readiness: compiled PDF page boundary
• Reproducibility checklist: command-to-artifact matrix
• Submission readiness: draft upload gate
• Paper claim ledger: claim-to-evidence map
• Mobile-tier readiness: Android/iOS readiness probe
• Mobile evidence pack: T2/T3 capture templates · execution playbook
• Draft frozen subset: planning manifest · readiness report
• Mobile test strategy: Android/iOS benchmark tiers
• Simulator launcher reference: simutil
• MobileCode Skill Spec: SKILL.md + WebView script + permission + verifier contract
• Harness Task Registry: task metadata for Tools, sheets, routes, skills and benchmark evidence
• v0 dry run evidence: 2026-06-06 representative run
• smoke-v2 T0 evidence: 2026-06-06 60-task smoke run

Recent on-device AI applications are moving from plain chat demos toward task galleries, skill packages, tool bridges, model/runtime management and benchmark views. Google AI Edge Gallery is a useful public example of this product shape: it organizes on-device models around tasks, custom tasks, skills, MCP tooling and benchmark surfaces. MobileCode adopts the pattern but changes the object of evaluation. Instead of becoming a general model gallery, MobileCode turns phone-native AI coding into a harness: incoming files, artifact editing, HTML/Markdown preview, GitHub delivery, runtime routing, verifier contracts and evidence reports.

The practical design consequence is now explicit in the repo:

• Skills use SKILL.md, scripts/index.html, permission tokens and verifier contracts.
• Tools, sheets and pages are promoted into a Harness Task Registry instead of remaining one-off buttons.
• Benchmark Lab is becoming an in-app surface for MobileHarnessBench status, task tiers and evidence boundaries.
• Claims remain evidence-bound: T0 fixture runs, mobile tiers, GitHub sandbox delivery and baseline comparison are reported separately.

These thumbnails are generated from the live GitHub Pages demos with just-thumbnail, so the README shows rendered pages rather than mock claims.

Demo Lab Product landing and demo index published on GitHub Pages.

2048 Web Touch-first generated HTML game for mobile WebView checks.

GitHub Test Browser-side token and repo access verification page.

flowchart LR
  A["User prompt on phone"] --> B["AI generates HTML / code artifact"]
  B --> C["Local WebView preview"]
  C --> D["HTML publish readiness check"]
  D --> E["GitHub Pages publish"]
  E --> F["Shareable work card"]
  B --> G["GitHub Repo Hub"]
  G --> H["Contents API edit + commit"]
  G --> I["GitHub Actions workflow_dispatch"]
  I --> J["Jobs, logs, artifacts"]

• Runtime abstraction: RuntimeProvider, RuntimeManager, Helper, External Termux, planned Embedded Lite, Cloud, and WebViewOnly fallback.
• MobileCode Helper prototype: health, execute, streaming logs, task stop, task state, preflight checks.
• Chat and agent process UI: model call progress, stop control, trace cards, generated artifact cards.
• HTML-first generation: built-in HTML/UI skill context, publish readiness checks, WebView preview, browser open, GitHub Pages publish.
• GitHub-first workspace: repo list, watchlist, language/Pages/local filters, local existence status, Remote-linked folder marker.
• Safe container architecture: multi-workspace, multi-runtime, multi-preview, and evidence-ledger model for phone-native AI coding.
• GitHub Actions surface: workflows, latest run status, jobs/steps, workflow dispatch, artifact zip download record.
• API-backed file flow: browse remote tree, read text files, edit, commit via GitHub Contents API, reload on SHA conflict.
• Extension management: Roles, Skill, MCP, Memory, Agent, Hook Registry surfaces for role-based workflows.
• Observability: RR AgentView, pending role approvals, Token Usage/cache-hit statistics, searchable/sortable LiteLLM-style pricing with manual snapshot checks, and Device Telemetry htop-style phone health.
• Lark Native API plan: agent-facing, Node-free Lark OpenAPI tools for Docs, Drive, Sheets, Bitable, Wiki, and evidence publishing; official CLI/MCP remain Mac/CI development probes, not embedded app runtimes.

MobileCode is the phone-native layer for agent control, artifact review, and release evidence. The long-term runtime direction is a Termux-like substrate (git + node + python + shell) that is invoked by the app as a service, while the user stays in MobileCode's control surface.

It should not be an embedded Termux terminal UI, and it should not become a generic remote IDE shell. The phone is still the command center: chat, role controls, route selection, previews, and shipping actions remain first-class inside MobileCode.

• Layer 1 - MobileCode App: conversations, tool cards, prompt state, repo selection, publish checks, and evidence surfaces.
• Layer 2 - Termux-like Runtime: long-term execution substrate for commands and project-level tooling, with isolation, caching, and runtime profiles.
• Layer 3 - Bridge Layer: typed runtime API, auth/session binding, intent routing, quota + timeout policy, and cancellation semantics.
• Layer 4 - Evidence Layer: command traces, logs, verifier signals, publish artifacts, and reproducibility records.

flowchart TB
  A["MobileCode App\nAgent UI / control / evidence cards"] --> B["Bridge Layer\nIntents / auth / quotas / telemetry"]
  B --> C["Termux-like Runtime\nGit / Node / Python / Shell"]
  B --> D["Remote Service Backends\nGitHub Actions / providers"]
  C --> E["Runtime output + logs"]
  E --> F["Evidence Layer\nTrace card / verifier feed / artifacts"]
  F --> A

Current repo implementation has runtime abstractions and helper paths in place; the full Termux-like embedded substrate is a roadmap objective, not a completed production feature yet.

flowchart TB
  UI["Flutter App\nChat · Files · Preview · Settings"] --> RM["RuntimeManager"]
  RM --> H["MobileCode Helper\nAndroid foreground service / daemon"]
  RM --> T["External Termux\nfallback shell"]
  RM --> W["WebViewOnly\npreview-only fallback"]
  RM --> C["Cloud Runtime\nheavy tasks later"]
  UI --> GH["GitHub Deep Service"]
  GH --> Repo["Repos / Contents API"]
  GH --> Pages["GitHub Pages"]
  GH --> Actions["GitHub Actions"]
  Actions --> Artifacts["APK / Web / release artifacts"]

Open:

• Demo Lab
• 2048 Web Demo
• GitHub Test

cd app
npm install
npm run build

Non-multimodal small tasks should default to cxspark: README/docs drafts, narrow code patches, checklists, prompt edits, and mechanical changes. The parent Codex session still owns planning, review, verification, commits, releases, visual/device QA, and any risky operation. See cxspark Agent Workflow.

Local Flutter SDK is required:

cd mobile_agent
flutter pub get
flutter create --platforms=android,ios .
flutter build apk --release

For release QA, prefer GitHub Actions so the build is reproducible:

• Mobile Runtime CI
• Build Android APK
• Android App Smoke Test

python scripts/generate_mobile_harness_task_bank.py
python scripts/run_mobile_harness_bench.py --task-set representative-v0 --run-id 2026-06-06-v0-dry-run
python scripts/run_mobile_harness_bench.py --task-set smoke-v2 --run-id 2026-06-06-smoke-v2-t0
python scripts/audit_mobile_harness_task_bank.py
python scripts/collect_mobile_harness_mobile_tier_evidence.py
python scripts/generate_mobile_harness_mobile_evidence_pack.py
python scripts/generate_mobile_harness_frozen_subset.py
python scripts/generate_mobile_harness_verifier_contract_readiness.py
python scripts/generate_mobile_harness_baseline_protocol.py
python scripts/generate_mobile_harness_baseline_run_contract.py
python scripts/generate_mobile_harness_baseline_scaffold.py
python scripts/generate_mobile_harness_baseline_dry_run.py
python scripts/generate_mobile_harness_baseline_pilot_pack.py
python scripts/generate_mobile_harness_baseline_pilot_readiness.py
python scripts/generate_mobile_harness_claim_ledger.py
python scripts/generate_mobile_harness_core_claim_readiness.py
python scripts/generate_mobile_harness_evidence_maturity_matrix.py
python scripts/generate_mobile_harness_evaluation_protocol_readiness.py
python scripts/generate_mobile_harness_method_presentation_readiness.py
python scripts/generate_mobile_harness_bibliography_readiness.py
python scripts/generate_mobile_harness_threats_to_validity.py
python scripts/generate_mobile_harness_page_limit_readiness.py
python scripts/generate_mobile_harness_reproducibility_checklist.py
python scripts/generate_mobile_harness_submission_readiness.py
python scripts/validate_mobile_harness_bench.py
python scripts/prepare_mobile_harness_supplement.py

The benchmark line is intentionally evidence-bound. The current data contains 25 v0 seed tasks, a 200-task v1 candidate bank and a 1000-task v2 candidate bank. v2 expands the taxonomy from five categories to six by adding runtime orchestration, mobile profiles, test oracles and Android/iOS test tiers.

The App-side Benchmark Lab mirrors this structure as a product surface: task registry, evidence tiers, verifier readiness, T0 runs, mobile evidence pack and open gates are visible in the phone UI without overstating readiness artifacts as completed experiments.

MobileCode does not try to become a full Termux clone. The long-term model is:

Flutter App
  -> RuntimeProvider abstraction
  -> MobileCode Helper
  -> External Termux fallback
  -> Embedded Lite runtime later
  -> Cloud runtime for heavy builds
  -> GitHub Pages + GitHub Actions for shipping

That keeps the phone lightweight while still letting users produce shareable web pages, inspect repos, commit small changes, and build APKs through GitHub Actions.

.
├─ app/                     React/Vite product site
├─ docs/                    GitHub Pages demos, QA docs, runtime docs
├─ mobile_agent/            Flutter app source
│  ├─ lib/screens/          Home, GitHub Repo Hub, Skill/MCP/Agent/Memory UI
│  ├─ lib/services/         Runtime, GitHub, Pages, Helper, skill services
│  └─ assets/               Role avatars and icons
├─ mobile-coding-*.md       Product and architecture analysis
└─ README.md                Project homepage

Current candidate: v0.1.68-mobile-harness-d2dd9a7.

See:

• Latest dual app build - Android APK, iOS simulator app, and iOS unsigned archive all completed successfully.
• Release assets - Android APK plus iOS simulator/archive artifacts.
• Version Policy
• Release QA Checklist
• Helper Runtime Protocol
• Production Hardening Notes

This repository is actively moving toward a deployable mobile coding workspace. The Android build path is GitHub Actions-first; local machines without Flutter/Android SDK should use CI artifacts instead of local builds.

No license file is included yet. Add a LICENSE before treating this as a reusable open-source distribution.