feat(mobile): rename a thread from the thread list menu

[spiky02plateau]

Renaming a thread to a chosen title works on web (sidebar row menu and chat header) but is unreachable on mobile, where the row menu only offers automatic title regeneration. The command side needs nothing: thread.meta.update already accepts a manual title (not capability-gated, unlike regenerateTitle), the decider already cancels an in-flight regeneration when a manual title arrives, and mobile already instantiates the exact updateMetadata mutation for regeneration. The gap is UI only.

This follows #5648, which proposed the same thing and was closed as already added. I went looking for where it landed before writing this and could not find it: on current main, git grep -i rename apps/mobile/src matches only file-diff rename notices, the v1 row menu composes Archive / Regenerate title / Delete, the v2 menus compose their settle/snooze/pin/archive/delete sets plus Regenerate title, and neither the thread settings sheet nor the thread header offers a title edit. If it did land somewhere I missed, happy to close this too.

The change mirrors the regenerate-title pattern: a renameThread action in useThreadListActions (the prompt lives in the hook, same as useConfirmDeleteThread, so the rows stay dumb), a "Rename" item in both the v1 and v2 row menus next to Regenerate title, on both the Home list and the iPad sidebar. Since the codebase has no text-prompt primitive (Alert.prompt is iOS-only and unused), ConfirmDialogHost gains a prompt variant: same imperative style, same theming, field prefilled with the current title, confirm disabled while the field trims to empty. Committing an unchanged title is a no-op; the commit rules (trim, reject empty) are ported from web's resolveRenameCommit.

Verification

• tsgo --noEmit in apps/mobile: error output identical to the origin/main baseline (all pre-existing react-navigation typing noise; zero errors in touched files, verified by diffing against a stashed baseline run)
• vp lint and vp fmt --check on all seven touched files: clean
• vp test run src/features/threads/thread-title-regeneration-menu.test.ts: 3 passed, as a no-regression check on the adjacent menu logic

Screenshots

I could not produce simulator captures for this one (no iOS or Android toolchain on this machine); describing the two states instead. Long-pressing a thread row shows the existing context menu with "Rename" between the pin/archive items and "Regenerate title". Selecting it opens a modal titled "Rename thread" with the current title prefilled and selected, Cancel and Rename buttons, Rename disabled while the field is empty. The dialog is the same custom in-app modal on both platforms, styled by the existing ConfirmDialogHost. I can add real captures if wanted.

Change made by Claude Opus via Claude Code.

---

Note

Low Risk
UI-only thread metadata update via an existing mutation; no auth or new backend surface. Dialog host is a small shared primitive with empty-title guards.

Overview
Lets users rename a thread from the Home and iPad sidebar row menus (v1 and v2), matching web’s manual title edit.

A Rename item sits next to regenerate-title. It opens a new cross-platform showPromptDialog on ConfirmDialogHost (keyboard-aware, prefilled/selected title, confirm disabled when blank). Commit uses existing updateMetadata with web’s trim / empty / no-op rules; failures surface via Alert. Rename is not capability-gated.

^{Reviewed by Cursor Bugbot for commit 0e1bed6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add Rename action to mobile thread list menus

• Refactors ConfirmDialogHost.tsx to render single-field prompt dialogs alongside confirm dialogs using a new presentDialog dispatcher and DialogRequest union type.
• Adds renameThread to useThreadListActions.ts to open a prompt, trim the input, ignore no-ops, and call updateMetadata with the new title.
• Wires onRenameThread through HomeScreen.tsx and the v1/v2 thread list row components to surface the RENAME_MENU_ACTION.
• Behavioral Change: ConfirmDialogHost replaces the presentRequest singleton with presentDialog, wraps content in KeyboardAvoidingView, and disables the confirm button when prompt input is empty.

📊 Macroscope summarized 0e1bed6. 7 files reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/mobile/src/features/home/HomeScreen.tsx — 0 comments posted, 1 evaluated, 1 filtered

• line 849: The newly captured props.onRenameThread is missing from the dependency arrays of both renderV2Item and renderItem. If the parent supplies a new rename callback (for example after one of that callback's hook dependencies changes), these memoized renderers continue passing the old callback to rows, so Rename can execute against stale mutation/dialog state until some other listed dependency changes. Add props.onRenameThread to both callback dependency arrays. [ Out of scope (post-validation triage) ]

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 048bfe89-5927-408e-af8d-762b453cf80d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This adds a new cross-platform thread-renaming workflow, including a shared prompt-dialog variant and persisted metadata writes wired through both mobile thread-list variants and Home/iPad sidebar surfaces. Despite reusing the existing command contract, the new user-facing behavior and shared UI change warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}