[Mobile] Edit workspace text files directly from the Files viewer

[camchis]

Supersedes #14444, which limited editing to Markdown. Originally proposed in #14438, where Julius's triage confirmed the mobile editing gap is real and not a duplicate.

Problem or use case

I want to make small edits to workspace files from the T3 Code mobile app without prompting an agent: fixing a line in AGENTS.md, correcting a config value, tweaking a README, or changing a constant in a source file. Mobile can browse workspace files, show their source or a rendered preview, and copy their contents, but it cannot save a change. For a one-line fix I have to ask an agent or switch to another client.

Web and desktop already edit any workspace text file in place. Mobile should be able to make the same kind of change.

Proposed behavior

1. Open a workspace text file from the Files browser, the tablet file navigator, or a file link in chat.
2. Tap Edit. The source opens in a plain monospace text editor with selection, copy/paste, undo, and keyboard-aware scrolling. Autocorrect, auto-capitalization, and spell check are off so they cannot alter code or paths.
3. Tap Save to write the file to the connected environment's workspace without starting an agent turn. The file view then shows the saved contents.
4. Tap Cancel to leave without writing. With unsaved changes, every way out (back button, swipe back, Android back, picking another file, returning to the thread) asks before discarding.

The editor shows the workspace-relative path so it is clear which file will change. Saving targets the same environment and worktree the file was opened from, including over remote connections, and never writes a copy on the phone.

If a save fails or the connection drops, the draft stays and Save can be retried. Success is shown only after the server confirms the write.

If an agent or another device changed the file after editing began, the save is refused instead of overwriting it. The user can overwrite anyway, discard the draft and reload, or keep editing.

Smallest useful scope

• Any workspace text file that web and desktop can edit today: a workspace-relative path that loaded in full (not truncated) and is not binary. Markdown and AGENTS.md are the common case, but a plain-text editor works the same for every text file, so limiting it to .md would add a check without reducing the work.
• iOS and Android, phone and tablet, through the existing React Native file flows.
• Plain source editing only. No syntax highlighting while editing; the existing highlighted viewer and Markdown preview stay as they are.
• Read-only as today: attachments, host files outside the workspace, truncated files, and media and PDF previews.
• Existing files only. No creating, renaming, or deleting files.

Out of scope: syntax-highlighted or rich-text editing, Markdown formatting tools, a mobile IDE, and keeping unsaved drafts after the OS kills the app (a possible follow-up).

Saving changes the file on disk. It should not promise that a running provider session reloads it, for example after editing AGENTS.md.

Implementation context

Most of the transport already exists:

• Mobile already exposes projectEnvironment.writeFile (packages/client-runtime/src/state/projectCommands.ts), but no mobile screen calls it.
• ThreadFileScreen (apps/mobile/src/features/files/ThreadFilesRouteScreen.tsx) loads the file and owns the file actions. Phones and the tablet pane share it.
• WorkspaceFileSystem.writeFile resolves the path inside the requested workspace and writes it. No provider adapter changes are needed.

Proposed changes:

• Conflict detection on the server. Add an optional revision (a hash of the bytes read) to ProjectReadFileResult, an optional expectedRevision to ProjectWriteFileInput, and a file_changed failure. When expectedRevision is present, the server re-reads the current file and refuses the write if it differs or no longer exists. Web and desktop send neither field and are unaffected. This also stops a save from replacing a file whose read came back short (fix(server): finish short reads before returning workspace text #14989), because the hashes will not match.
• Version skew. The mobile app and servers update independently, and an older server would ignore expectedRevision and write anyway. Mobile therefore offers Edit only when the read result includes revision; files on older servers stay read-only.
• The editor is its own screen, opened from the file view. One guard then catches every way of leaving with unsaved changes, and the existing viewer is untouched. The route carries the resolved workspace path, so a save cannot land in a different checkout.
• Line endings. The mobile source viewer converts CRLF to LF for display. The editor starts from the raw contents and restores CRLF on save.
• Size. A single native text input holding a large file may type slowly on Android. The largest editable size should be chosen by measuring, with larger files staying read-only.

Questions for maintainers

1. Explicit Save or autosave? Web autosaves after 500 ms. On mobile, often over a relay, I propose explicit Save and Cancel so "saved" means the server confirmed the write and the conflict check runs once against a known version. Is that difference from web acceptable?
2. Contract change. Are optional revision and expectedRevision fields acceptable, or would you prefer a different conflict check?
3. Permissions. feat(auth): separate filesystem read and write permissions #9788 adds filesystem:write. Should this wait for it, so Edit only appears for connections with write access?

Willingness to contribute

I'm happy to build this once direction and scope are agreed, as one PR covering the contract, server, and mobile changes, with focused server tests.

Acceptance criteria

• On iOS and Android, a user can open a workspace text file (for example AGENTS.md, package.json, or a source file), change it, and save it without sending a prompt or starting a turn.
• The same flow works whether the file was opened from Files, the tablet navigator, or a chat file link.
• Saved contents land in the selected environment and worktree and appear in the file view after saving.
• Cancel leaves the file unchanged, and no navigation path silently discards an unsaved draft.
• A failed save or a dropped connection keeps the draft and allows a retry.
• A file that changed on disk after editing began is not overwritten unless the user chooses to, and the draft stays available.
• Files with CRLF line endings keep them after saving.
• Attachments, host files, truncated files, and media stay read-only.
• Existing browsing and previews on phones and tablets, and existing web and desktop editing, keep working.

Related work

• [Feature][Mobile] Edit workspace Markdown files directly, including AGENTS.md #14438: the original proposal and maintainer triage.
• Edit workspace Markdown files directly via Mobile app #14444: the earlier Markdown-only version of this idea, superseded by this one.
• feat(auth): separate filesystem read and write permissions #9788: separate filesystem:read and filesystem:write permissions (open).
• fix(server): finish short reads before returning workspace text #14989: short reads can return part of a file without marking it truncated (open).
• [Bug]: Closing a file tab overwrites newer on-disk changes #8475: web overwrote newer on-disk changes when a tab closed (fixed in fix(web): avoid stale file writes on close #8630). The same risk shapes the conflict check here.
• feat(web): add in-place lexical markdown editor to file preview #11637: a Lexical rich-text Markdown editor for web (closed draft). It does not cover the React Native app.