[Feature]: Allow checked-in t3.json setup actions to run without per-user import

[husseinraoouf]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

t3.json can define an action with runOnWorktreeCreate: true, but it does nothing until each user manually imports that action. I miss Codex's code-first setup flow, where repository setup travels with the code.

Proposed solution

Let the worktree setup runner use the checked-in action directly from t3.json. This could be gated by repository trust or a managed opt-in, with approval requested again if the command changes.

Why this matters

Teams could keep setup in one checked-in place instead of relying on every teammate to repeat UI configuration or discover that their worktree was not initialized.

Smallest useful scope

When there is no saved setup action, load the runOnWorktreeCreate action from t3.json after the repository has been trusted.

Alternatives considered

Manual import is easy to miss and can drift from the file. Agent instructions run too late, and Git hooks require separate setup; #551 also notes that their output is currently hidden.

Risks or tradeoffs

Running repository code is a trust boundary, so automatic setup should require explicit repository trust or an administrator-controlled policy.

Examples or references

Related: #551, which covers Git hook output rather than using t3.json directly.

Contribution

• I would be open to helping implement this.

[drake-nathan]

+1 for my team. We have multiple devs on our team using T3 Code (thank you!).

Our worktree setup is checked in as t3.json → scripts/[worktree-setup.sh]. It copies gitignored files like .env` and generated Prisma clients from the main checkout, then installs dependencies. Without it, a new worktree thread can't typecheck or run tests.

The per-user import is where it breaks down for a team:

• Every person has to find Settings → Projects → Actions → Import from t3.json.
• Imported copies don't follow changes to t3.json ([Bug]: Imported actions keep stale t3.json commands and hide updates #18061). When we change the setup command, everyone has to re-import.
• Other tools we use read checked-in setup directly, so T3 is the one place where repo setup doesn't travel with the code.

Something like the trust gate you described would cover our needs. Run the t3.json setup action directly, ask once per repo (and again when the command changes), and keep a per-user override to disable it.