fix(security): Confirm repo-provided setup script before running

[charlesvien]

Problem

Resolves VERIA-353: RCE via untrusted repository configuration.

Changes

Ask before running a repo-provided environment setup script, and stop silently auto-selecting the first repo-provided environment. The prompt is shown on every run rather than remembered: the script text does not determine what the command does, so a stored approval for npm run setup would still hold after the repository changed what that runs.

How did you test this?

Unit tests in @posthog/ui: the confirm gate returns the user's answer, prompts on every run, and warns that the script can execute other repository files; the selector never selects an environment on its own.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

[charlesvien]

• fix(security): Open files in external apps via argv not shell #3805
• fix(security): Confirm repo-provided setup script before running #3804 👈 (View in Graphite)
• fix(security): Enforce CSP on sandboxed MCP app HTML #3803
• fix(security): Run setup discovery agent in plan mode #3802
• fix(security): Scope MCP UI resource caches by server name #3801
• fix(security): Validate agent slug before building ingress host #3800
• fix(security): Keep OAuth token out of terminal environments #3799
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit fd3a090.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/core/src/task-detail/taskCreationHost.ts, line 121-127 (link)

   Parallel setup approval system

   This models setup authorization as a custom host method backed by durable UI-store state, creating a second authorization system whose persistence, auditing, and cross-host behavior must be maintained separately from the established permission-tool flow.

   Context Used: CLAUDE.md (source)

   Knowledge Base Used:

   • Shared foundation: packages/shared, packages/core, packages/di
   • @posthog/ui shared UI package
   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/core/src/task-detail/taskCreationHost.ts
   Line: 121-127
   
   Comment:
   **Parallel setup approval system**
   
   This models setup authorization as a custom host method backed by durable UI-store state, creating a second authorization system whose persistence, auditing, and cross-host behavior must be maintained separately from the established permission-tool flow.
   
   **Context Used:** CLAUDE.md ([source](https://github.com/posthog/code/blob/main/CLAUDE.md))
   
   **Knowledge Base Used:**
   - [Shared foundation: `packages/shared`, `packages/core`, `packages/di`](https://app.greptile.com/posthog-org-19734/-/custom-context/knowledge-base/posthog/code/-/docs/shared-foundation.md)
   - [`@posthog/ui` shared UI package](https://app.greptile.com/posthog-org-19734/-/custom-context/knowledge-base/posthog/code/-/docs/ui-package.md)
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/core/src/task-detail/taskCreationHost.ts:121-127
**Parallel setup approval system**

This models setup authorization as a custom host method backed by durable UI-store state, creating a second authorization system whose persistence, auditing, and cross-host behavior must be maintained separately from the established permission-tool flow.

### Issue 2 of 2
packages/ui/src/features/task-detail/taskCreationHostImpl.ts:204
**Approval read precedes hydration**

This reads persisted approvals without checking `_hasHydrated`, so task creation during the desktop store's asynchronous hydration sees the initial empty map and unnecessarily prompts again for an already approved script.

_{Reviews (1): Last reviewed commit: "confirm repo-provided setup script befor..." | Re-trigger Greptile}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[github-actions]

Security-sensitive fix (gating repo-provided setup script execution behind explicit confirmation), but both flagged review concerns are verifiably fixed in the diff — approval is keyed to the exact script text (re-prompts if the script changes, addressing veria-ai's reuse concern) and the hydration race greptile flagged is now guarded before reading persisted approvals — and a security-focused agent reviewer's latest comment confirms no open security concerns remain, giving independent assurance over the risky surface.

• Author wrote 0% of the modified lines and has 19 merged PRs in these paths (familiarity MODERATE).
• 👍 on the PR from greptile-apps[bot].
• Greptile raised an unresolved architectural point (discussion comment) that this introduces a second, parallel authorization system alongside the existing permission-tool flow — a design concern worth follow-up, not a blocking defect.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	84L, 5F substantive, 260L/9F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1c-medium (260L, 9F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ bf27356 · reviewed head 2dd6bde

[trunk-io]

😎 This pull request was merged.

New commits pushed (delta classified non_linear_history) — stamphog approval dismissed; re-review running automatically.

[stamphog]

Note

🤖 stamphog reviewed fd3a09045ecab7de72cdb12a56bbf6ada0174b8a — verdict: ESCALATE

This is a security-sensitive change to the setup-script execution/authorization flow (RCE fix), and both bot reviews are stale (older commit). Greptile's unaddressed architecture/security concern — that this introduces a second, ad-hoc authorization system (a raw window.confirm) parallel to the project's established permission-tool flow, with separate persistence/auditing behavior — is not resolved in the current diff and was never responded to.

• 👍 on the PR from greptile-apps[bot].
• Greptile's 'Parallel setup approval system' comment (taskCreationHost.ts) flags that confirmEnvironmentSetup creates a bespoke authorization mechanism (window.confirm) instead of routing through the established permission-tool flow — unaddressed in the diff and unresponded to.
• Both existing bot reviews (veria-ai, greptile-apps) are marked COMMENTED on an older commit (8ee7112), not the current head, so their sign-off doesn't verifiably cover the latest changes.
• This is auth/security-sensitive surface (fixing an RCE via untrusted repo config) — per policy this cannot be self-certified without independent assurance tied to the current head.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	41L, 4F substantive, 128L/7F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1c-medium (128L, 7F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ e60a53a · reviewed head fd3a090

Updated in place — this replaces 2 earlier stamphog review(s) on this PR.