fix(copilot): bar the headless client-tool fallback below write

Client-routed tools carry no catalog requiredPermission because the browser runs
them through the workflow APIs, which authorize the caller's own session. The
headless fallback in executeTool has no session and runs under the request's
principal instead, with nothing standing in for that check.

So the read cap from the previous commit did not reach run_workflow,
run_workflow_until_block, run_block or run_from_block: all four are route
'client' with no requiredPermission, unlike create_workflow and edit_workflow.
An unattributed inbox sender could therefore still run an existing workflow,
which executes with enforceCredentialAccess under the workspace owner and
resolves the owner's workspace and personal secrets.

Derive the requirement at the gate instead: a client-routed tool taking the
headless fallback requires write. Interactive callers never reach this branch,
so the browser path is unaffected. The catalog itself is generated from the
copilot contracts repo and cannot carry this rule, which only applies to the
fallback.

Also corrects the inboxToolPermission doc, which claimed run_workflow gates on
requiredPermission 'write'. It does not; it is gated here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/lib/copilot/tool-executor/executor.test.ts

@@ -242,14 +242,48 @@ describe('copilot tool executor fallback', () => {
     const runWorkflowHandler = vi.fn().mockResolvedValue({ success: true, output: { ran: true } })
     registerHandler('run_workflow', runWorkflowHandler)
 
-    const context = { userId: 'user-1', workflowId: 'workflow-1', workspaceId: 'ws-1' }
+    const context = {
+      userId: 'user-1',
+      workflowId: 'workflow-1',
+      workspaceId: 'ws-1',
+      userPermission: 'write',
+    }
     const result = await executeTool('run_workflow', { workflow_input: {} }, context)
 
     expect(runWorkflowHandler).toHaveBeenCalledWith({ workflow_input: {} }, context)
     expect(executeAppTool).not.toHaveBeenCalled()
     expect(result).toEqual({ success: true, output: { ran: true } })
   })
 
+  /**
+   * `run_workflow` carries no catalog permission — the browser path authorizes it through the
+   * workflow APIs against the caller's own session. The headless fallback has no session, so
+   * without a bar of its own a deliberately capped run (an unattributed inbox message) would
+   * still execute workflows under the principal it was capped away from.
+   */
+  it.each([['read'], [undefined]] as const)(
+    'refuses the headless client fallback for a %s permission',
+    async (userPermission) => {
+      isKnownTool.mockReturnValue(true)
+      isSimExecuted.mockReturnValue(false)
+      isClientExecuted.mockReturnValue(true)
+
+      const runWorkflowHandler = vi.fn().mockResolvedValue({ success: true })
+      registerHandler('run_workflow', runWorkflowHandler)
+
+      const result = await executeTool(
+        'run_workflow',
+        { workflow_input: {} },
+        { userId: 'user-1', workflowId: 'workflow-1', workspaceId: 'ws-1', userPermission }
+      )
+
+      expect(result.success).toBe(false)
+      expect(result.error).toContain('requires write access')
+      expect(runWorkflowHandler).not.toHaveBeenCalled()
+      expect(executeAppTool).not.toHaveBeenCalled()
+    }
+  )
+
   it('falls back to app tool executor for client-routed tools with no registered handler', async () => {
     isKnownTool.mockReturnValue(true)
     isSimExecuted.mockReturnValue(false)

apps/sim/lib/copilot/tool-executor/executor.ts

@@ -38,7 +38,26 @@ export async function executeTool(
   params: Record<string, unknown>,
   context: ToolExecutionContext
 ): Promise<ToolExecutionResult> {
-  const requiredPermission = getToolEntry(toolId)?.requiredPermission
+  // Client-routed tools (e.g. run_workflow) are normally executed in the browser and never
+  // reach this point in interactive mode. In headless mode (Mothership block, no browser) there
+  // is no client to delegate to, so fall back to the registered server-side handler when one
+  // exists — otherwise the call would route to executeAppTool and throw "Tool not found".
+  const usesHeadlessClientFallback = isClientExecuted(toolId) && hasHandler(toolId)
+
+  /**
+   * Client-routed tools carry no catalog `requiredPermission` because the browser runs them
+   * through the workflow APIs, which authorize the caller's own session. The headless fallback
+   * has no session to authorize against and runs under the request's principal instead, so it
+   * has to supply a bar of its own.
+   *
+   * Without one, a run whose permission was deliberately capped still reaches `run_workflow`,
+   * and `runWorkflowFromCopilot` executes with `enforceCredentialAccess` — resolving the
+   * principal's workspace and personal secrets. That is the hole an unattributed inbox message
+   * leaves open: `resolveInboxExecutionActor` refuses it a secret actor, but the run still
+   * carries the workspace owner as principal.
+   */
+  const requiredPermission =
+    getToolEntry(toolId)?.requiredPermission ?? (usesHeadlessClientFallback ? 'write' : undefined)
   if (
     requiredPermission &&
     !permissionSatisfies(
@@ -54,13 +73,8 @@ export async function executeTool(
 
   const normalizedParams = normalizeToolParams(toolId, params, context)
 
-  // Client-routed tools (e.g. run_workflow) are normally executed in the browser and never
-  // reach this point in interactive mode. In headless mode (Mothership block, no browser) there
-  // is no client to delegate to, so fall back to the registered server-side handler when one
-  // exists — otherwise the call would route to executeAppTool and throw "Tool not found".
   const canUseRegisteredHandler =
-    isKnownTool(toolId) &&
-    (isSimExecuted(toolId) || (isClientExecuted(toolId) && hasHandler(toolId)))
+    isKnownTool(toolId) && (isSimExecuted(toolId) || usesHeadlessClientFallback)
   if (!canUseRegisteredHandler) {
     const appParams = buildAppToolParams(normalizedParams, context)
     const options = {

apps/sim/lib/mothership/inbox/executor.ts

@@ -370,9 +370,11 @@ interface InboxExecutionActor {
  * An unattributed message resolves to the workspace owner so the run has a real
  * user for billing and workspace reads, and the owner is typically an admin. Left
  * alone, that hands an allowlisted external correspondent the owner's write
- * authority: `create_workflow`, `edit_workflow` and `run_workflow` all gate on
- * `requiredPermission: 'write'`, and a workflow built and run through them executes
- * with `enforceCredentialAccess`, resolving the owner's workspace *and personal*
+ * authority: `create_workflow` and `edit_workflow` gate on
+ * `requiredPermission: 'write'`, and `run_workflow` is gated by the headless
+ * client-fallback bar in `executeTool` — it carries no catalog permission of its
+ * own. A workflow built or run through any of them executes with
+ * `enforceCredentialAccess`, resolving the owner's workspace *and personal*
  * secrets. That is the same reach `secretActorUserId: null` already refuses for a
  * direct mount, so refusing it here keeps one answer rather than two.
  *