[Bug]: "Open preview automatically when this action runs" has no effect

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Open a project and click the actions (scripts) menu → Add action.
2. Fill in a name and a command that starts a dev server (e.g. pnpm dev).
3. Set Preview URL to http://localhost:5173, enable Open preview automatically when this action runs, and save.
4. Reopen the modal — both settings are correctly persisted (this part was fixed by #3842).
5. Run the action from the actions menu, with the preview panel closed.

The preview panel never opens.

Note on how this was found: this is a source-level analysis against main @ 64bf016, not a runtime bisect. The code path is unambiguous though — see below.

Expected behavior

Per the schema documentation, the preview panel opens at previewUrl the moment the action starts:

autoOpenPreview — "When true, automatically open the preview panel pointed at previewUrl the moment this script starts. Ignored without previewUrl or on web."
— packages/contracts/src/orchestration.ts:206-208 (same wording in packages/contracts/src/t3ProjectFile.ts:50-55)

This is also what the modal's own helper text promises for the Preview URL field: "Open this URL in the in-app preview when this action runs" (ProjectScriptsControl.tsx:575).

Actual behavior

autoOpenPreview has no runtime consumer anywhere in the monorepo. runProjectScript (apps/web/src/components/ChatView.tsx:2792-2890) opens or reuses a terminal, writes ${script.command}\r, handles the two failure results, and returns — it never reads script.autoOpenPreview or script.previewUrl.

Grepping autoOpenPreview across apps/ and packages/ on current main returns only the form state in ProjectScriptsControl.tsx, the mapper in projectScripts.ts, the two schemas, and tests. Nothing in web, desktop, mobile or server acts on it.

previewUrl does have one surviving consumer: getConfiguredPreviewUrls (apps/web/src/components/preview/previewEmptyStateLogic.ts:7) seeds the preview panel's empty-state "Local servers" list, so a configured URL appears there as a clickable row. That requires the panel to already be open on the empty state, and a manual click.

Where it went. The behavior existed when the preview panel landed in 52c77c1 (feat(preview): in-app browser preview panel), at the end of runProjectScript:

if (
  script.autoOpenPreview &&
  script.previewUrl &&
  isPreviewSupportedInRuntime() &&
  activeThreadRef
) {
  try {
    const snapshot = await api.preview.open({
      threadId: activeThreadId,
      url: script.previewUrl,
    });
    usePreviewStateStore.getState().applyServerSnapshot(activeThreadRef, snapshot);
    useRightPanelStore.getState().openBrowser(activeThreadRef, snapshot.tabId);
  } catch {
    // Preview open failures are surfaced via the panel itself.
  }
}

e95b57d (#2978, [codex] Rewrite client connection architecture) rewrote runProjectScript onto the atom-command API and dropped that block, along with the persistence of both fields in saveProjectScript.

Why it looks fixed but isn't. #3842 ("Fix project action preview settings persistence", closing #4172) restored the persistence half via buildProjectScript — but it only touched the save paths, not runProjectScript. So the reported symptom (fields clearing on reopen) went away, and the dropped behavior stayed dropped. The persistence bug was effectively masking this one: users hit the clearing first and reported that.

Restoring it looks like re-fitting the block above to the current API — openTerminal/writeTerminal now return AtomCommandResult values rather than throwing, and useRightPanelStore.openBrowser still takes (threadRef, tabId).

One adjacent thing worth deciding in the same change: since #4317 added both fields to the shared t3.json project-file schema, a team can now commit autoOpenPreview to a repo and expect it to work. Either the behavior comes back, or both fields should be removed from the modal, the contracts and the project-file schema — but the current state documents a feature that does nothing.

Impact

Minor bug or occasional failure

Version or commit

main @ 64bf016 (2026-08-01). Also present in the released CLI (checked against t3 v0.0.31).

Environment

Source analysis of the main branch; not tied to one OS or build. The dropped code path is desktop-only by design (isPreviewSupportedInRuntime()), so any repro needs a desktop build.

Logs or stack traces

# No errors are produced — the auto-open call is simply absent, so the action
# runs successfully and nothing else happens.

Workaround

Open the preview panel manually. A configured Preview URL still appears in the panel's empty-state "Local servers" list, so it is one click rather than typing the URL — but the panel has to be opened by hand first (mod+shift+J, or the globe toggle in the header).

Start in apps/web/src/components/ChatView.tsx at runProjectScript and compare its current flow with the prior preview-opening block described in the issue. Read the preview state and right-panel APIs, then check the existing action-related tests. Done means a configured action opens the preview automatically when supported, while preserving the documented behavior for missing URLs and web runtime.