fix(tui): pass workspace on yolo auto-approve and stop duplicate replies

Two defects introduced by the previous review round, found by CodeRabbit.

The workspace was never sent on the flush path. `set()` took an optional
workspace argument, but the app.tsx caller did not pass one, so replies from
flushPendingPermissions went out with `workspace: undefined` while the session
permission UI sends `project.workspace.current()` on every reply. Fixed at the
source instead of at the call site — sync already has the project context, and
threading the value through each caller is how it went missing in the first
place.

Replies could be sent twice for one request. flushPendingPermissions does not
remove requests from the store; removal waits for the server's
`permission.replied` event. Toggling yolo off and on again, or two set() calls,
therefore replied to an already-settled id. The server rejects the second reply
and autoApprove treated that rejection as a lost reply, putting a prompt back on
screen for a request that was already answered. Now guarded by an in-flight set
for concurrent duplicates plus optimistic removal on success for sequential
ones — the event handler's removal stays idempotent.

Adds a regression test for the double-enable path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01964Prd1Sz5JwWZmNTrFdiU

Author: Haider

packages/tui/src/context/sync.tsx

@@ -282,26 +282,63 @@ export const {
       )
     }
 
+    // Remove a settled permission request from the store. Idempotent — both the
+    // `permission.replied` event and a successful auto-approve call it.
+    function removePermission(sessionID: string, requestID: string) {
+      const requests = store.permission[sessionID]
+      if (!requests?.length) return
+      const match = search(requests, requestID, (r) => r.id)
+      if (!match.found) return
+      setStore(
+        "permission",
+        sessionID,
+        produce((draft) => {
+          draft.splice(match.index, 1)
+        }),
+      )
+    }
+
+    // Requests currently being auto-approved. A reply is not removed from
+    // store.permission until the server's `permission.replied` event lands, so without
+    // this a second flush (toggle off then on again, or two set() calls) would reply to
+    // the same request twice. The second reply targets an already-settled request, the
+    // server rejects it, and the rejection would be misread as a lost reply — putting a
+    // prompt back on screen for something already answered.
+    const autoApproving = new Set<string>()
+
     // Auto-approve on behalf of the user. MUST fail loudly: the handler does not enqueue
     // the request, so if the reply is lost the server-side Deferred in Permission.ask
     // never settles and the agent hangs with nothing on screen explaining why.
     //
     // `throwOnError: true` is required — the generated SDK client defaults to returning
     // `{ error }` rather than throwing (packages/sdk/js/src/gen/client/client.gen.ts), so
     // a plain `.catch()` here would never fire on an ordinary HTTP failure.
+    //
+    // The workspace is read here rather than taken from callers: the session permission
+    // UI passes `project.workspace.current()` on every reply, and threading it through
+    // each call site is exactly how it went missing on the flush path.
     async function autoApprove(request: PermissionRequest, workspace?: string) {
+      if (autoApproving.has(request.id)) return
+      autoApproving.add(request.id)
       try {
         await sdk.client.permission.reply(
-          { requestID: request.id, reply: "once", workspace },
+          { requestID: request.id, reply: "once", workspace: workspace ?? project.workspace.current() },
           { throwOnError: true },
         )
+        // Drop it now rather than waiting for the server's `permission.replied` event.
+        // The in-flight set above only covers concurrent duplicates; a later flush (toggle
+        // off, then on again) would still find the request sitting in the store and reply
+        // to an already-settled id. The event handler's removal is idempotent.
+        removePermission(request.sessionID, request.id)
       } catch (e) {
         console.error("yolo mode auto-approve failed", {
           error: e instanceof Error ? e.message : String(e),
           requestID: request.id,
         })
         // Fall back to asking the user rather than silently swallowing the request.
         enqueuePermission(request)
+      } finally {
+        autoApproving.delete(request.id)
       }
     }
 

packages/tui/test/cli/cmd/tui/yolo-sync.test.tsx

@@ -220,6 +220,32 @@ describe("tui sync: yolo auto-approve", () => {
     }
   })
 
+  // Regression: flushPendingPermissions does not remove requests from the store — that
+  // waits for the server's permission.replied event. Toggling off and on again, or two
+  // set() calls, would otherwise reply to the same request twice; the server rejects the
+  // second, autoApprove misreads the rejection as a lost reply, and a prompt reappears
+  // for a request that was already answered.
+  test("enabling twice does not reply to the same request twice", async () => {
+    const { app, emit, sync, replies, tmp } = await setup()
+    try {
+      emit(askEvent(ROOT, "perm_1"))
+      await wait(() => pending(sync, ROOT).length === 1)
+
+      sync.yolo.set(ROOT, true)
+      await wait(() => replies.length === 1)
+      // Second enable while the first reply is still settling.
+      sync.yolo.set(ROOT, true)
+      await Bun.sleep(300)
+
+      expect(replies).toHaveLength(1)
+      // And no phantom prompt got re-inserted.
+      expect(pending(sync, ROOT)).toHaveLength(0)
+    } finally {
+      app.renderer.destroy()
+      await tmp[Symbol.asyncDispose]()
+    }
+  })
+
   test("deleting a session drops its yolo override", async () => {
     const { app, emit, sync, tmp } = await setup()
     try {