Surface pending tasks in mobile home and draft flow

[juliusmarminge]

Summary

• Shows queued pending tasks in the mobile home and thread sidebar lists, grouped with their parent project alongside active threads.
• Adds actions to open, edit, and delete pending tasks from the list UI.
• Extends the new-task draft flow so offline tasks are queued to the outbox and can later be resumed or resent from the draft screen.
• Refines thread composer styling and preserves draft state for pending-task edits and workspace start-from-origin settings.

Testing

• Not run (not requested).
• Project checks required by repo policy were not run in this summary.

---

Note

Medium Risk
Changes thread-outbox delivery, persistence schema, and turn-identifier reuse for pending tasks; incorrect gating could duplicate threads or drop queued work, though the PR adds targeted tests and edit locks.

Overview
Queued new tasks now appear in the mobile home and thread sidebar lists (ahead of threads, grouped by project), with rows to open, edit, or delete unsent outbox items.

The new-task draft path enqueues when the environment is disconnected (queue affordance vs start), resumes editing via pendingTaskId, and adds a Start from origin worktree option. Pending edits use a dedicated draft key, hold the outbox drain while open, and flush changes back on dismiss.

The thread outbox gains a creation payload (schema v3), in-place updates, and drain rules that treat new-thread creations separately (wait until shell is live, skip incomplete payloads, remove when the thread already exists). Immediate send and drain share buildProjectThreadStartTurnInput so online and offline delivery match.

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

Note

Surface pending tasks in mobile home screen and new task draft flow

• Adds PendingTaskListRow to home and sidebar lists so queued (unsent) tasks appear alongside threads, grouped by project, with tap-to-edit and long-press delete actions.
• Extends the outbox model with a creation payload (schema v3) and a new update operation so pending thread-creation tasks can be stored, edited, and redelivered when a shell comes online.
• NewTaskDraftScreen now queues a task in the outbox when the environment is offline, supports editing previously queued tasks, and shows a queue icon on the start button when offline.
• NewTaskFlowProvider gains beginEditingPendingTask/finishEditingPendingTask lifecycle, a startFromOrigin toggle for worktree mode, and holds the outbox drain while a task is being edited.
• The outbox drain (useThreadOutboxDrain) dispatches queued creations once the project shell is live, skips messages under active editing, and removes tasks whose project is missing.
• Risk: Schema version bump to 3 means persisted outbox messages written by older clients won't include creation metadata; the decoder accepts older versions gracefully.

^{Macroscope summarized 34f3a2c.}

[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

Run ID: ef114159-9305-4698-b959-604e9cab8a6c

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/92d0f1f6-c5c5-4400-9d63-5e62b109203e

---

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

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 4 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for all 4 issues found in the latest run.

• ✅ Fixed: Pending edit survives draft pop
  • Added cancelEditingPendingTask that triggers the flush (clears editingPendingTaskRef, editingPendingTask state, and editingQueuedMessageId) and called it from a cleanup effect in NewTaskDraftScreen so editing state is properly cleared when the draft screen unmounts.
• ✅ Fixed: Deleted pending resurrected on dismiss
  • The flush now checks findQueuedPendingTask before re-enqueuing so deleted tasks are not resurrected, and confirmDeletePendingTask now calls setEditingQueuedMessageId(null) to immediately unblock the drain.
• ✅ Fixed: Route project skipped after re-entry
  • Added a cleanup effect that resets appliedInitialProjectKeyRef to null on unmount so re-entering the draft screen with the same project correctly applies it via setProject.
• ✅ Fixed: Flush unblocks drain before enqueue
  • Deferred setEditingQueuedMessageId(null) into the .finally() callback of enqueueThreadOutboxMessage so the drain guard remains active until the updated message is persisted.

Or push these changes by commenting:

@cursor push 5a9eae43c1

Preview (5a9eae43c1)

diff --git a/apps/mobile/src/features/home/usePendingTaskListActions.ts b/apps/mobile/src/features/home/usePendingTaskListActions.ts
--- a/apps/mobile/src/features/home/usePendingTaskListActions.ts
+++ b/apps/mobile/src/features/home/usePendingTaskListActions.ts
@@ -4,6 +4,7 @@
 
 import { removeThreadOutboxMessage } from "../../state/thread-outbox";
 import type { PendingNewTask } from "../../state/use-pending-new-tasks";
+import { setEditingQueuedMessageId } from "../../state/use-thread-outbox";
 
 export function usePendingTaskListActions(): {
   readonly openPendingTask: (pendingTask: PendingNewTask) => void;
@@ -35,6 +36,7 @@
           text: "Delete",
           style: "destructive",
           onPress: () => {
+            setEditingQueuedMessageId(null);
             void removeThreadOutboxMessage(pendingTask.message).catch((error) => {
               Alert.alert(
                 "Could not delete pending task",

diff --git a/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx b/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
--- a/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
+++ b/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
@@ -80,14 +80,26 @@
   const promptInputRef = useRef<ComposerEditorHandle>(null);
   const loadedBranchesProjectKeyRef = useRef<string | null>(null);
   const appliedInitialProjectKeyRef = useRef<string | null>(null);
+  useEffect(() => {
+    return () => {
+      appliedInitialProjectKeyRef.current = null;
+    };
+  }, []);
 
-  const { beginEditingPendingTask, editingPendingTask } = flow;
+  const { beginEditingPendingTask, cancelEditingPendingTask, editingPendingTask } = flow;
   useEffect(() => {
     if (props.pendingTaskId && editingPendingTask?.messageId !== props.pendingTaskId) {
       beginEditingPendingTask(props.pendingTaskId);
     }
   }, [beginEditingPendingTask, editingPendingTask?.messageId, props.pendingTaskId]);
 
+  useEffect(() => {
+    if (!props.pendingTaskId) return;
+    return () => {
+      cancelEditingPendingTask();
+    };
+  }, [props.pendingTaskId, cancelEditingPendingTask]);
+
   const borderColor = useThemeColor("--color-border");
   const bodyText = useScaledTextRole("body");
   const sheetFadeOpaque = colorScheme === "dark" ? "rgba(14,14,14,0.98)" : "rgba(242,242,247,0.98)";

diff --git a/apps/mobile/src/features/threads/new-task-flow-provider.tsx b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
--- a/apps/mobile/src/features/threads/new-task-flow-provider.tsx
+++ b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
@@ -135,6 +135,7 @@
   readonly setStartFromOrigin: (value: boolean) => void;
   readonly beginEditingPendingTask: (messageId: string) => void;
   readonly finishEditingPendingTask: () => void;
+  readonly cancelEditingPendingTask: () => void;
   readonly buildPendingTaskMessage: (metadata: TurnCommandMetadata) => QueuedThreadMessage | null;
   readonly setPrompt: (value: string) => void;
   readonly replaceAttachments: (attachments: ReadonlyArray<DraftComposerImageAttachment>) => void;
@@ -603,8 +604,8 @@
     setEditingQueuedMessageId(null);
   }, []);
 
-  // Leaving the flow mid-edit (sheet dismissed) saves the current edits back
-  // into the queued task so nothing typed here is lost.
+  // Leaving the flow mid-edit (sheet dismissed or draft screen popped) saves
+  // the current edits back into the queued task so nothing typed here is lost.
   const editingFlushRef = useRef<(() => void) | null>(null);
   useEffect(() => {
     editingFlushRef.current = () => {
@@ -613,21 +614,38 @@
         return;
       }
       editingPendingTaskRef.current = null;
-      const message = buildPendingTaskMessage({
-        threadId: editing.threadId,
-        commandId: editing.commandId,
-        messageId: editing.messageId,
-        createdAt: editing.createdAt,
-      });
+      setEditingPendingTask(null);
+
+      // If the task was deleted externally, skip re-enqueuing.
+      const stillQueued = findQueuedPendingTask(editing.messageId);
+
+      const message = stillQueued
+        ? buildPendingTaskMessage({
+            threadId: editing.threadId,
+            commandId: editing.commandId,
+            messageId: editing.messageId,
+            createdAt: editing.createdAt,
+          })
+        : null;
+
+      clearComposerDraft(pendingTaskDraftKey(editing.messageId));
+
       if (message) {
-        void enqueueThreadOutboxMessage(message).catch((error) => {
-          console.warn("[new-task] failed to save edited pending task", error);
-        });
+        void enqueueThreadOutboxMessage(message)
+          .catch((error) => {
+            console.warn("[new-task] failed to save edited pending task", error);
+          })
+          .finally(() => {
+            setEditingQueuedMessageId(null);
+          });
+      } else {
+        setEditingQueuedMessageId(null);
       }
-      clearComposerDraft(pendingTaskDraftKey(editing.messageId));
-      setEditingQueuedMessageId(null);
     };
   }, [buildPendingTaskMessage]);
+  const cancelEditingPendingTask = useCallback(() => {
+    editingFlushRef.current?.();
+  }, []);
   useEffect(
     () => () => {
       editingFlushRef.current?.();
@@ -673,6 +691,7 @@
       setStartFromOrigin,
       beginEditingPendingTask,
       finishEditingPendingTask,
+      cancelEditingPendingTask,
       buildPendingTaskMessage,
       setPrompt,
       replaceAttachments,
@@ -694,6 +713,7 @@
       branchQuery,
       branchesLoading,
       buildPendingTaskMessage,
+      cancelEditingPendingTask,
       editingPendingTask,
       environments,
       expandedProvider,

_{You can send follow-ups to the cloud agent here.}

[macroscopeapp]

🟠 High state/use-pending-new-tasks.ts:11

PendingNewTask exposes only the queued message and creation.projectId, forcing buildHomeThreadGroups to re-resolve each pending task against the live projects snapshot. When an environment is offline or its project metadata has not loaded yet, the project lookup fails, so buildHomeThreadGroups drops those tasks entirely — queued tasks vanish from Home/Sidebar precisely while they are waiting for reconnection. Consider persisting enough project metadata (title and grouping fields) on PendingNewTask so pending tasks remain visible without a live project lookup.

Also found in 2 other location(s)

apps/mobile/src/features/home/homeThreadList.ts:95

buildHomeThreadGroups drops any pending task whose creation.projectId no longer appears in input.projects (groupKeyByProjectKey.get(...) returns nothing and the loop just continues). The new home screen now treats pendingTasks.length > 0 as enough to suppress the true empty state, so if a queued task belongs to a project that was removed or has not been loaded yet, the screen shows an empty thread list and the user loses the only UI path to reopen or delete that pending draft.

apps/mobile/src/features/home/HomeScreen.tsx:322

hasAnyThreads at line 322 treats any queued pendingTasks as if the Home list has displayable content, but buildHomeThreadGroups() only shows a pending task when its creation.projectId still matches a project in props.projects. If the task belongs to a deleted/missing project or to a filtered-out environment, projectGroups stays empty while hasAnyThreads is still true, so the screen skips the real empty/loading state and renders the generic list-empty branch instead. Users can end up seeing No threads yet/No threads in … while their queued task is invisible and the normal add-connection/loading messaging is suppressed.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/state/use-pending-new-tasks.ts around line 11:

`PendingNewTask` exposes only the queued `message` and `creation.projectId`, forcing `buildHomeThreadGroups` to re-resolve each pending task against the live `projects` snapshot. When an environment is offline or its project metadata has not loaded yet, the project lookup fails, so `buildHomeThreadGroups` drops those tasks entirely — queued tasks vanish from Home/Sidebar precisely while they are waiting for reconnection. Consider persisting enough project metadata (title and grouping fields) on `PendingNewTask` so pending tasks remain visible without a live project lookup.

Also found in 2 other location(s):
- apps/mobile/src/features/home/homeThreadList.ts:95 -- `buildHomeThreadGroups` drops any pending task whose `creation.projectId` no longer appears in `input.projects` (`groupKeyByProjectKey.get(...)` returns nothing and the loop just `continue`s). The new home screen now treats `pendingTasks.length > 0` as enough to suppress the true empty state, so if a queued task belongs to a project that was removed or has not been loaded yet, the screen shows an empty thread list and the user loses the only UI path to reopen or delete that pending draft.
- apps/mobile/src/features/home/HomeScreen.tsx:322 -- `hasAnyThreads` at line `322` treats any queued `pendingTasks` as if the Home list has displayable content, but `buildHomeThreadGroups()` only shows a pending task when its `creation.projectId` still matches a project in `props.projects`. If the task belongs to a deleted/missing project or to a filtered-out environment, `projectGroups` stays empty while `hasAnyThreads` is still `true`, so the screen skips the real empty/loading state and renders the generic list-empty branch instead. Users can end up seeing `No threads yet`/`No threads in …` while their queued task is invisible and the normal add-connection/loading messaging is suppressed.

[macroscopeapp]

Approvability

Verdict: Needs human review

5 blocking correctness issues found. This PR introduces a new feature for surfacing pending tasks with substantial new logic across multiple files. Multiple high-severity unresolved review comments identify potential bugs including data loss scenarios and race conditions that warrant human review before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[juliusmarminge]

@cursor push 5a9eae4

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Delete races pending edit flush
  • Fixed both races by (1) deferring setEditingQueuedMessageId(null) until removeThreadOutboxMessage resolves so the drain cannot send a deleting message, and (2) tracking pending deletions in a shared Set so the editor's unmount flush bails out instead of re-enqueuing a task whose async removal is in progress.

Or push these changes by commenting:

@cursor push 1736b9ecc2

Preview (1736b9ecc2)

diff --git a/apps/mobile/src/features/home/usePendingTaskListActions.ts b/apps/mobile/src/features/home/usePendingTaskListActions.ts
--- a/apps/mobile/src/features/home/usePendingTaskListActions.ts
+++ b/apps/mobile/src/features/home/usePendingTaskListActions.ts
@@ -2,7 +2,11 @@
 import { useCallback } from "react";
 import { Alert } from "react-native";
 
-import { removeThreadOutboxMessage } from "../../state/thread-outbox";
+import {
+  clearPendingDeletion,
+  markPendingDeletion,
+  removeThreadOutboxMessage,
+} from "../../state/thread-outbox";
 import type { PendingNewTask } from "../../state/use-pending-new-tasks";
 import { setEditingQueuedMessageId } from "../../state/use-thread-outbox";
 
@@ -36,13 +40,18 @@
           text: "Delete",
           style: "destructive",
           onPress: () => {
-            setEditingQueuedMessageId(null);
-            void removeThreadOutboxMessage(pendingTask.message).catch((error) => {
-              Alert.alert(
-                "Could not delete pending task",
-                error instanceof Error ? error.message : "The pending task could not be removed.",
-              );
-            });
+            markPendingDeletion(pendingTask.message.messageId);
+            void removeThreadOutboxMessage(pendingTask.message)
+              .catch((error) => {
+                Alert.alert(
+                  "Could not delete pending task",
+                  error instanceof Error ? error.message : "The pending task could not be removed.",
+                );
+              })
+              .finally(() => {
+                clearPendingDeletion(pendingTask.message.messageId);
+                setEditingQueuedMessageId(null);
+              });
           },
         },
       ],

diff --git a/apps/mobile/src/features/threads/new-task-flow-provider.tsx b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
--- a/apps/mobile/src/features/threads/new-task-flow-provider.tsx
+++ b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
@@ -41,6 +41,7 @@
 import {
   enqueueThreadOutboxMessage,
   flattenQueuedThreadMessages,
+  isPendingDeletion,
   threadOutboxManager,
   type QueuedThreadMessage,
 } from "../../state/thread-outbox";
@@ -616,6 +617,13 @@
       editingPendingTaskRef.current = null;
       setEditingPendingTask(null);
 
+      // If a deletion is in progress, bail out and let the delete handler
+      // manage the editing lock and cleanup.
+      if (isPendingDeletion(editing.messageId)) {
+        clearComposerDraft(pendingTaskDraftKey(editing.messageId));
+        return;
+      }
+
       // If the task was deleted externally, skip re-enqueuing.
       const stillQueued = findQueuedPendingTask(editing.messageId);
 

diff --git a/apps/mobile/src/state/thread-outbox.ts b/apps/mobile/src/state/thread-outbox.ts
--- a/apps/mobile/src/state/thread-outbox.ts
+++ b/apps/mobile/src/state/thread-outbox.ts
@@ -27,3 +27,17 @@
 export function clearThreadOutboxEnvironment(environmentId: EnvironmentId): Promise<void> {
   return threadOutboxManager.clearEnvironment(environmentId);
 }
+
+const pendingDeletionMessageIds = new Set<string>();
+
+export function markPendingDeletion(messageId: string): void {
+  pendingDeletionMessageIds.add(messageId);
+}
+
+export function clearPendingDeletion(messageId: string): void {
+  pendingDeletionMessageIds.delete(messageId);
+}
+
+export function isPendingDeletion(messageId: string): boolean {
+  return pendingDeletionMessageIds.has(messageId);
+}

_{You can send follow-ups to the cloud agent here.}

[macroscopeapp]

🟠 High threads/new-task-flow-provider.tsx:562

buildPendingTaskMessage reads selectedProject for environmentId, projectId, projectTitle, and projectCwd, but during an editing session the user can switch environments before closing the sheet. The flush path then rewrites the queued task with fields from the newly selected project, silently moving it to a different environment/repository. The rebuilt message should preserve those fields from the original editingPendingTask instead of the live selectedProject.

Also found in 1 other location(s)

apps/mobile/src/state/use-thread-outbox-drain.ts:258

sendQueuedCreation rebuilds the bootstrap payload with project.workspaceRoot instead of the queued snapshot in creation.projectCwd. If the project path changes after the task was queued, the offline outbox no longer sends the same command that was originally saved and can create the thread/worktree from the wrong directory. The queued message already persists creation.projectCwd, so this regression is introduced at the resend path.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/features/threads/new-task-flow-provider.tsx around line 562:

`buildPendingTaskMessage` reads `selectedProject` for `environmentId`, `projectId`, `projectTitle`, and `projectCwd`, but during an editing session the user can switch environments before closing the sheet. The flush path then rewrites the queued task with fields from the newly selected project, silently moving it to a different environment/repository. The rebuilt message should preserve those fields from the original `editingPendingTask` instead of the live `selectedProject`.

Also found in 1 other location(s):
- apps/mobile/src/state/use-thread-outbox-drain.ts:258 -- `sendQueuedCreation` rebuilds the bootstrap payload with `project.workspaceRoot` instead of the queued snapshot in `creation.projectCwd`. If the project path changes after the task was queued, the offline outbox no longer sends the same command that was originally saved and can create the thread/worktree from the wrong directory. The queued message already persists `creation.projectCwd`, so this regression is introduced at the resend path.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 3 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for all 3 issues found in the latest run.

• ✅ Fixed: Drain drops visible pending tasks
  • Changed sendQueuedCreation to accept a projectCwd string and the drain now falls back to creation.projectCwd instead of dropping the message when the project shell is absent from the catalog.
• ✅ Fixed: Wrong project while editing pending
  • Prevented selectedProject from falling back to projectsForEnvironment[0] when editingPendingTask is set, so buildPendingTaskMessage and handleStart cannot target the wrong project.
• ✅ Fixed: Pending open never retries load
  • Added queuedMessages to the effect dependency list so it retries when the outbox hydrates, moved attemptedPendingTaskIdRef assignment to after success, and deferred navigation until the outbox has content.

Or push these changes by commenting:

@cursor push 8432c98136

Preview (8432c98136)

diff --git a/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx b/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
--- a/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
+++ b/apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
@@ -34,7 +34,12 @@
 import { useScaledTextRole } from "../settings/appearance/useScaledTextRole";
 import { getComposerDraftSnapshot } from "../../state/use-composer-drafts";
 import { useProjects } from "../../state/entities";
-import { enqueueThreadOutboxMessage, removeThreadOutboxMessage } from "../../state/thread-outbox";
+import {
+  enqueueThreadOutboxMessage,
+  flattenQueuedThreadMessages,
+  removeThreadOutboxMessage,
+} from "../../state/thread-outbox";
+import { useThreadOutboxMessages } from "../../state/use-thread-outbox";
 import { useRemoteConnectionStatus } from "../../state/use-remote-environment-registry";
 import { branchBadgeLabel, useNewTaskFlow } from "./new-task-flow-provider";
 import { useCreateProjectThread } from "./use-project-actions";
@@ -84,6 +89,7 @@
   }, []);
 
   const { beginEditingPendingTask, cancelEditingPendingTask, editingPendingTask } = flow;
+  const queuedMessages = useThreadOutboxMessages();
   const attemptedPendingTaskIdRef = useRef<string | null>(null);
   useEffect(() => {
     if (!props.pendingTaskId || editingPendingTask?.messageId === props.pendingTaskId) {
@@ -94,12 +100,21 @@
     if (attemptedPendingTaskIdRef.current === props.pendingTaskId) {
       return;
     }
+    if (beginEditingPendingTask(props.pendingTaskId)) {
+      attemptedPendingTaskIdRef.current = props.pendingTaskId;
+      return;
+    }
+    // The task was not found. If the outbox atom is still empty, persisted
+    // messages may not have hydrated yet — wait for the next atom update.
+    const hasOutboxContent =
+      flattenQueuedThreadMessages(queuedMessages).length > 0;
+    if (!hasOutboxContent) {
+      return;
+    }
+    // The outbox has content but this task is absent — it was sent or deleted.
     attemptedPendingTaskIdRef.current = props.pendingTaskId;
-    if (!beginEditingPendingTask(props.pendingTaskId)) {
-      // The queued task no longer exists (sent or deleted before opening).
-      navigation.dispatch(StackActions.replace("NewTask"));
-    }
-  }, [beginEditingPendingTask, editingPendingTask?.messageId, navigation, props.pendingTaskId]);
+    navigation.dispatch(StackActions.replace("NewTask"));
+  }, [beginEditingPendingTask, editingPendingTask?.messageId, navigation, props.pendingTaskId, queuedMessages]);
 
   useEffect(() => {
     if (!props.pendingTaskId) return;

diff --git a/apps/mobile/src/features/threads/new-task-flow-provider.tsx b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
--- a/apps/mobile/src/features/threads/new-task-flow-provider.tsx
+++ b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
@@ -262,8 +262,7 @@
     projectsForEnvironment.find(
       (project) => scopedProjectKey(project.environmentId, project.id) === selectedProjectKey,
     ) ??
-    projectsForEnvironment[0] ??
-    null;
+    (editingPendingTask !== null ? null : (projectsForEnvironment[0] ?? null));
   const selectedEnvironmentServerConfig = useEnvironmentServerConfig(
     selectedProject?.environmentId ?? null,
   );

diff --git a/apps/mobile/src/state/use-thread-outbox-drain.ts b/apps/mobile/src/state/use-thread-outbox-drain.ts
--- a/apps/mobile/src/state/use-thread-outbox-drain.ts
+++ b/apps/mobile/src/state/use-thread-outbox-drain.ts
@@ -244,7 +244,7 @@
     async (
       queuedMessage: QueuedThreadMessage,
       creation: QueuedThreadCreation,
-      project: EnvironmentProject,
+      projectCwd: string,
     ) => {
       const modelSelection = queuedMessage.modelSelection;
       if (modelSelection === undefined) {
@@ -255,7 +255,7 @@
         environmentId: queuedMessage.environmentId,
         input: buildProjectThreadStartTurnInput({
           projectId: creation.projectId,
-          projectCwd: project.workspaceRoot,
+          projectCwd,
           threadId: queuedMessage.threadId,
           commandId: queuedMessage.commandId,
           messageId: queuedMessage.messageId,
@@ -341,13 +341,14 @@
         );
       const creationProject =
         creation !== undefined ? findCreationProject(projects, nextQueuedMessage) : undefined;
+      const creationProjectCwd = creationProject?.workspaceRoot ?? creation?.projectCwd;
       const delivery =
         deliveryAction === "remove"
           ? removeQueuedMessage("[thread-outbox] failed to remove message for a missing thread")
           : creation !== undefined
-            ? creationProject !== undefined
-              ? sendQueuedCreation(nextQueuedMessage, creation, creationProject)
-              : removeQueuedMessage("[thread-outbox] dropped pending task for a missing project")
+            ? creationProjectCwd !== undefined
+              ? sendQueuedCreation(nextQueuedMessage, creation, creationProjectCwd)
+              : Promise.resolve(false)
             : thread !== undefined
               ? sendQueuedMessage(nextQueuedMessage, thread)
               : Promise.resolve(false);

_{You can send follow-ups to the cloud agent here.}

[macroscopeapp]

🟠 High home/usePendingTaskListActions.ts:15

openPendingTask navigates straight to NewTaskDraft using pendingTask.creation.projectId without verifying the project still exists. When the original project no longer exists locally, the draft flow falls back to projectsForEnvironment[0], so resending the queued task silently sends it against the wrong project. Consider checking the project is still available before navigating, and showing an error or fallback UI if it is not.

Also found in 1 other location(s)

apps/mobile/src/state/use-thread-outbox-drain.ts:258

sendQueuedCreation rebuilds the bootstrap payload with project.workspaceRoot instead of the persisted creation.projectCwd. A queued worktree task is therefore no longer tied to the repository path it was created for: if that project's workspaceRoot changes before the outbox drains, the resend will prepare the worktree in the new cwd and start the thread against the wrong checkout.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/features/home/usePendingTaskListActions.ts around line 15:

`openPendingTask` navigates straight to `NewTaskDraft` using `pendingTask.creation.projectId` without verifying the project still exists. When the original project no longer exists locally, the draft flow falls back to `projectsForEnvironment[0]`, so resending the queued task silently sends it against the wrong project. Consider checking the project is still available before navigating, and showing an error or fallback UI if it is not.

Also found in 1 other location(s):
- apps/mobile/src/state/use-thread-outbox-drain.ts:258 -- `sendQueuedCreation` rebuilds the bootstrap payload with `project.workspaceRoot` instead of the persisted `creation.projectCwd`. A queued worktree task is therefore no longer tied to the repository path it was created for: if that project's `workspaceRoot` changes before the outbox drains, the resend will prepare the worktree in the new cwd and start the thread against the wrong checkout.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 3 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for all 3 issues found in the latest run.

• ✅ Fixed: Failed flush unlocks outbox drain
  • Moved setEditingQueuedMessageId(null) from .finally() into .then() (guarded by editingPendingTaskRef.current === null) so the drain lock is only released on successful save, preventing stale content delivery on failure.
• ✅ Fixed: Stale flush clears active draft
  • Guarded clearComposerDraft in .then() with a check that editingPendingTaskRef.current?.messageId !== editing.messageId, so the draft is preserved when the user has reopened the same pending task before the earlier flush settles.
• ✅ Fixed: Invalid cwd triggers outbox send
  • In buildPendingTaskMessage, projectCwd now checks selectedProject.workspaceRoot !== String(selectedProject.id) before persisting, so the fabricated stand-in value (stringified project ID) is stored as undefined instead of a non-path string that would pass the drain's null gate.

Or push these changes by commenting:

@cursor push 39d3cb2de2

Preview (39d3cb2de2)

diff --git a/apps/mobile/src/features/threads/new-task-flow-provider.tsx b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
--- a/apps/mobile/src/features/threads/new-task-flow-provider.tsx
+++ b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
@@ -612,7 +612,10 @@
         creation: {
           projectId: selectedProject.id,
           projectTitle: selectedProject.title,
-          projectCwd: selectedProject.workspaceRoot,
+          projectCwd:
+            selectedProject.workspaceRoot !== String(selectedProject.id)
+              ? selectedProject.workspaceRoot
+              : undefined,
           workspaceMode: mode,
           branch: workspaceSelection?.branch ?? null,
           worktreePath: mode === "worktree" ? null : (workspaceSelection?.worktreePath ?? null),
@@ -679,13 +682,15 @@
         // save keeps it around so the edits rehydrate on the next open).
         void updateThreadOutboxMessage(message)
           .then(() => {
-            clearComposerDraft(pendingTaskDraftKey(editing.messageId));
+            if (editingPendingTaskRef.current === null) {
+              setEditingQueuedMessageId(null);
+            }
+            if (editingPendingTaskRef.current?.messageId !== editing.messageId) {
+              clearComposerDraft(pendingTaskDraftKey(editing.messageId));
+            }
           })
           .catch((error) => {
             console.warn("[new-task] failed to save edited pending task", error);
-          })
-          .finally(() => {
-            setEditingQueuedMessageId(null);
           });
       } else {
         clearComposerDraft(pendingTaskDraftKey(editing.messageId));

_{You can send follow-ups to the cloud agent here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Edit lock handoff enables stale send
  • When the flush path finds an unsendable edit (empty prompt), the outbox row's text is now cleared via updateThreadOutboxMessage so that isQueuedThreadCreationSendable returns false even if the single-slot drain lock is later overwritten by opening another pending task.

Or push these changes by commenting:

@cursor push 7c800d3db5

Preview (7c800d3db5)

diff --git a/apps/mobile/src/features/threads/new-task-flow-provider.tsx b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
--- a/apps/mobile/src/features/threads/new-task-flow-provider.tsx
+++ b/apps/mobile/src/features/threads/new-task-flow-provider.tsx
@@ -700,9 +700,11 @@
 
       if (!message) {
         // The edits are currently unsendable (e.g. the prompt was cleared).
-        // Keep both the draft and the drain lock: the stale queued payload
-        // must not auto-send content the user just removed, and reopening the
-        // task resumes from the saved draft.
+        // Blank the outbox text so the entry itself fails
+        // `isQueuedThreadCreationSendable` — the drain lock alone is not
+        // sufficient because opening another pending task overwrites the
+        // single-slot lock atom and would release this one.
+        void updateThreadOutboxMessage({ ...editing, text: "" });
         return;
       }

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 2c7d991. Configure here.}

[macroscopeapp]

🟠 High state/use-thread-outbox.ts:29

editingQueuedMessageIdsAtom is a pure in-memory atom (Atom.keepAlive), but the queued outbox messages and the edit drafts it protects are persisted. If the user closes an edit without saving (leaving a draft and lock in composer-drafts) and then restarts the app, this atom resets to {} while the stale queued message remains on disk. The outbox drain only checks editingQueuedMessageIds[nextQueuedMessage.messageId], so on startup it no longer skips that messageId and auto-delivers the old payload — the stale content the user removed or edited. The edit lock needs to survive restarts so the drain keeps skipping a messageId whose draft is still unsaved.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/state/use-thread-outbox.ts around line 29:

`editingQueuedMessageIdsAtom` is a pure in-memory atom (`Atom.keepAlive`), but the queued outbox messages and the edit drafts it protects are persisted. If the user closes an edit without saving (leaving a draft and lock in `composer-drafts`) and then restarts the app, this atom resets to `{}` while the stale queued message remains on disk. The outbox drain only checks `editingQueuedMessageIds[nextQueuedMessage.messageId]`, so on startup it no longer skips that `messageId` and auto-delivers the old payload — the stale content the user removed or edited. The edit lock needs to survive restarts so the drain keeps skipping a `messageId` whose draft is still unsaved.

[macroscopeapp]

🟠 High state/use-thread-outbox-drain.ts:355

When the shell is "live" but the project snapshot has not yet loaded (findCreationProject returns undefined), the drain drops the queued creation via removeQueuedMessage("[thread-outbox] dropped pending task for a missing project") instead of waiting. A live connection can transiently expose an empty project list, so this permanently deletes a pending task whose project simply hasn't appeared yet. Consider treating a missing live project the same as a not-yet-loaded shell — continue to wait instead of removing the message.

Also found in 1 other location(s)

apps/mobile/src/features/threads/new-task-flow-provider.tsx:585

beginEditingPendingTask() checks isComposerDraftEmpty(getComposerDraftSnapshot(draftKey)) before the persisted composer drafts are guaranteed to be loaded. After an app restart, a pending-task edit draft can still exist on disk, but getComposerDraftSnapshot() initially sees an empty in-memory atom, so lines 585-598 rehydrate the draft from the stale queued message and overwrite the user's newer persisted edits. When ensureComposerDraftsLoaded() finishes later, it merges persisted drafts under the already-written in-memory draft, so the newer saved edits are lost.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/state/use-thread-outbox-drain.ts around line 355:

When the shell is `"live"` but the project snapshot has not yet loaded (`findCreationProject` returns `undefined`), the drain drops the queued creation via `removeQueuedMessage("[thread-outbox] dropped pending task for a missing project")` instead of waiting. A live connection can transiently expose an empty project list, so this permanently deletes a pending task whose project simply hasn't appeared yet. Consider treating a missing live project the same as a not-yet-loaded shell — `continue` to wait instead of removing the message.

Also found in 1 other location(s):
- apps/mobile/src/features/threads/new-task-flow-provider.tsx:585 -- `beginEditingPendingTask()` checks `isComposerDraftEmpty(getComposerDraftSnapshot(draftKey))` before the persisted composer drafts are guaranteed to be loaded. After an app restart, a pending-task edit draft can still exist on disk, but `getComposerDraftSnapshot()` initially sees an empty in-memory atom, so lines 585-598 rehydrate the draft from the stale queued message and overwrite the user's newer persisted edits. When `ensureComposerDraftsLoaded()` finishes later, it merges persisted drafts under the already-written in-memory draft, so the newer saved edits are lost.