[Silthus]

Problem

• To use the T3 Code step, a user creates a webhook task in T3 Code by hand and pastes its URL.

Impact: Grow Workflows: faster setup of the T3 Code step.

Note

Stacked on #127225 (flag gate and catalog entry), and also needs #127118 (Node template, on #127117). Moved from the fork PR #126492, which could not run CI.
Until #127118 merges, this diff also shows its Node template files.

Warning

🟡 Merge risk: medium · two-way door (merge-risk rubric)

• New endpoints write the step's webhook URL from T3 Code's reply. A wrong URL starts no thread.
• Limits: workflow-t3-code-step flag, signed-in members only, approval per call, stale replies dropped.
• Revert: revert the merge commit.

Changes

• The step gets a setup panel: pick a T3 Code machine and project, then create the task. PostHog fills in the URL.
• Machines are the T3 Code connections the member can use in MCP servers settings, their own or team-shared.
• Projects without a default model are disabled, because T3 Code needs one.
• A machine with more than 100 projects shows "Load more projects". Each page asks for approval, because an approval covers one call.
• The ready banner shows only while the webhook URL still points to the created task.
• A project list PostHog can't read asks the member to update T3 Code, instead of showing no projects.
• Mechanical: generated types, an mcp_store facade function, the skill reference, and a panel split with no visible change (not rendered).
• The lane-mix warning is expected: the Node files come from feat(workflows): add a T3 Code step that starts a T3 Code agent run #127118, and services/mcp types ship with the serializer.

More than 100 projects	Second page	Ready	URL edited

How did you test this code?

Test rationale: API tests with real MCP installations and a faked T3 Code catch leaked connections, self-approving API keys and hidden errors. Logic tests catch a late reply, or a late page of projects, from a machine the member left. A paging test catches a dropped cursor that hides projects after the first 100.

• Live run at 47c3b28 on a dev server: the picker paged a real T3 Code machine with 101 projects, created the task, and a saved workflow's test run started a thread whose agent replied.
• The run used T3 Code's local hook URL, because T3 Connect was off on that machine. The relay hop is not covered.
• The "Ready" screenshot stubs only the create reply, for the same reason.
• Not run: a production-build UI walk.

Release status

• This change is behind a feature flag and is not available to users

Docs update

• None.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: Claude Code, Claude Opus 5.5

Skills: /improving-drf-endpoints, /writing-tests, /writing-ui-components, /writing-pr-descriptions

More context for AI agents

Question	Answer	Who	Where
What should the step offer?	Pick a machine and project, start new threads there	👤 Human	comment
Keep #127118's owner rule?	No; #127118 drops it, private workflows (#126468) protect credentials. Replaces "yes"	👤 Human	comment
How does PostHog reach T3 Code?	The member's MCP connection (t3_project_list, schedule_task), not a new integration	🤖 Agent	comment
API tokens on the setup endpoints?	No, only a signed-in member, so approval stays with a person	🤖 Agent	comment
Team-shared connections?	Listed, because the admin shared them for members to use	🤖 Agent	comment
Change T3 Code's API?	No; the default-model limit has an open upstream fix (pingdotgg/t3code#16833)	🤖 Agent	comment
One PR or a stack?	One PR, because neither half works alone	🤖 Agent	comment

Involvement: design pass by GPT-6.1 Sol; qa-swarm panel rounds 1 (7 lenses) and 2 (6 lenses) with GPT-6.1 Sol and Claude Opus 5.5; seven final reads; live run captured, plus a replay-key run at 4492b78. On PostHog/posthog: a GPT-6.1 Sol review at 7101ee3 led to the paging fix; a final read led to the late-page guard.

• Session: T3 Code thread, Claude Code with T3 Code MCP tools and agent-browser.
• Decisions: the webhook URL field stays editable, so a pasted URL still works.
• Follow-ups: machines are keyed by host, like other MCP store member calls, so two connections on one host show as one. Deleting the step leaves its T3 Code task in place. A task created while T3 Connect is off stays unused when the member retries. T3 Code's open fix for model selection in schedule_task (fix(server): scheduled tasks created over MCP can set their model and effort pingdotgg/t3code#23566) would lift the default-model limit.
• Read closely: workflow_t3_code.py and the approval flow in t3CodeTaskSetupLogic.ts.

🤖 Generated with Claude Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit d21bc35.}

[scheduled-actions-posthog]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the stale label – otherwise this will be closed in another week. If you want to permanently keep it open, use the waiting label.

[Silthus]

Closed in the 2026-11-13 draft triage: no map or thread owns the T3 Code step, and nothing replaced it. The branch stays. Its webhook-signing base, #127117, goes ahead on its own.