[jayleaton]

The MacBook iOS captures of #226 found three problems on mobile:

1. Schedule type control (blocker). The five-segment control (At a time · Once · Interval · Cron · On webhook) overflowed at 402pt and 390pt. "On webhook" broke mid-word, "At a time" wrapped, and the selected pill turned into a circle. It's now a Runs menu row, the same SelectRow pattern "Runs go to" uses. The labels and the mode-switch behaviour are unchanged.
2. Cron time format. Cron rows printed the raw "Weekdays at 02:30" next to fixed-time rows in the device format ("9:00 am"). describeSchedule in client-runtime/scheduled-task-cron now takes an optional formatTimeOfDay. Mobile passes its device formatter, and web is unchanged.
3. "9:00 am GMT" for Asia/Bangkok (already on main). scheduleTimeZoneLabel read the zone name from formatToParts. When that part comes back as a bare "GMT" for a zone that isn't at UTC+0, the label now comes from the real offset ("GMT+7", "GMT+5:30"). The offset is read from the numeric date parts, because Effect's offset helper parses the same name part.
   • Not confirmed on a device: my guess is that Hermes on iOS splits "GMT+7" into a "GMT" name and a "+7" literal. Node prints "GMT+7", and this machine has no iOS Simulator to check. The new test simulates that split, and the fix holds whatever the cause, as long as the numeric parts are right.

Before (MacBook, #226):

After captures still to come. This machine can't run the iOS Simulator (no Xcode, so simctl is missing). The MacBook needs to capture the Runs row and its menu at 390pt in light and dark, and the list with a cron task and an Asia/Bangkok fixed-time task.

Verification

• Failing first: scheduledTaskTimeZone.test.ts "keeps the offset when the zone name part drops it" failed with expected 'GMT' to be 'GMT+7'. The new scheduledTaskCron.test.ts row failed with Weekdays at 14:30. Both pass after the fix.
• vp test run on the touched client-runtime and mobile tests gives 33 passed. Mobile typecheck reports 0 errors.
• vp run check:changed passes all steps.

Implemented by Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.5 KiB	21.5 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	1	1	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	1	1	0 (0.0%)	8	✅

Baseline: 97f71b5 · PR result: 3a56cea · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.