fix(mothership): scope mothership block tool permissions to the executing user

[TheodoreSpeaks]

Summary

• buildExecutionContext now reads userPermission from the request payload and sets it on the execution context, so Mothership block runs enforce the executing user's workspace permissions
• The execute route already resolved and forwarded userPermission, but the headless/block lifecycle path dropped it — tools ran with userPermission: undefined (writes either hard-denied or silently unenforced depending on the tool)
• Brings the block path to parity with the interactive Mothership chat path, which already sets this
• Added a regression test asserting payload userPermission propagates into the generated execution context

Type of Change

• Bug fix

Testing

Tested manually. run.test.ts passes (3/3); verified the new test fails without the fix. bun run lint clean; bun run check:api-validation:strict passed.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 2, 2026 1:57am

[cursor]

PR Summary

Medium Risk
Fixes authorization for tool execution on the block path; incorrect behavior before could block or mishandle writes, so the change is security-relevant but narrow and test-backed.

Overview
buildExecutionContext now copies userPermission from the copilot request payload onto ExecutionContext, matching how userTimezone and requestMode are already handled.

That closes a gap on the headless / Mothership block lifecycle path: the execute route could forward userPermission, but tools saw undefined and workspace write/read enforcement was wrong or inconsistent. Interactive chat already set this; block runs now get the same behavior.

A regression test in run.test.ts asserts payload userPermission: 'write' reaches the context passed into the stream loop.

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

[greptile-apps]

Greptile Summary

This PR fixes a permission-scoping gap in the Mothership block execution path: buildExecutionContext now reads userPermission from the incoming request payload and stamps it onto the generated ExecutionContext, bringing the headless/block lifecycle path to parity with the interactive Mothership chat path (post.ts), which already sets this field from a database lookup.

• run.ts: Extracts userPermission from requestPayload using the same defensive typeof … === 'string' guard and falsy-check pattern used for userTimezone and requestMode, then assigns it to execContext if present.
• run.test.ts: Adds a regression test that injects userPermission: 'write' into the payload and asserts it propagates into the captured ExecutionContext passed to runStreamLoop.

Confidence Score: 5/5

Safe to merge — the change is a minimal, targeted two-line addition that mirrors an already-established pattern in the same function.

The fix reads a server-generated value (already validated against the DB in the execute route) from the request payload, using the same defensive type-check and falsy-guard idiom used for userTimezone and requestMode immediately above it. The permission enforcement layer uses an allowlist approach, so any unexpected value safely falls through as read-only. The regression test directly captures the execution context passed to the stream loop and asserts the field is present.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/lib/copilot/request/lifecycle/run.ts	Two-line addition in buildExecutionContext that reads userPermission from the request payload and sets it on the execution context; follows the established pattern for userTimezone and requestMode exactly.
apps/sim/lib/copilot/request/lifecycle/run.test.ts	New regression test verifies that a userPermission value in the payload is correctly propagated into the execution context; test structure is consistent with the existing test suite.

Sequence Diagram

sequenceDiagram
    participant Executor as Workflow Executor
    participant Route as /api/mothership/execute
    participant DB as Database
    participant Headless as runHeadlessCopilotLifecycle
    participant Lifecycle as runCopilotLifecycle
    participant BuildCtx as buildExecutionContext
    participant Tools as Tool Router

    Executor->>Route: POST (internal JWT auth)
    Route->>DB: getUserEntityPermissions(userId, workspaceId)
    DB-->>Route: "userPermission (read|write|admin|null)"
    Note over Route: Build requestPayload with userPermission
    Route->>Headless: runHeadlessCopilotLifecycle(requestPayload, options)
    Headless->>Lifecycle: runCopilotLifecycle(requestPayload, options)
    Lifecycle->>BuildCtx: buildExecutionContext(requestPayload, params)
    Note over BuildCtx: NEW: reads userPermission from requestPayload
    BuildCtx-->>Lifecycle: execContext with userPermission set
    Lifecycle->>Tools: executeToolAndReport(execContext)
    Note over Tools: isWritePermission(execContext.userPermission) now correctly enforced

Loading

_{Reviews (1): Last reviewed commit: "fix(mothership): scope mothership block ..." | Re-trigger Greptile}