Support MCP Events in T3's MCP server

[nullStack65]

Why

External agents like ChatGPT can start T3 threads through MCP, but once their own turn ends, they aren't notified when those threads finish, fail, or need input.

MCP Events would let external agents subscribe to these changes and automatically resume their conversations, without polling or manual intervention.

How

• Add MCP 2026-07-28 support and expose events/list, events/subscribe, and events/unsubscribe through the existing /mcp endpoint.
• Reuse T3's existing run.updated and runtime-request.updated event streams to publish thread-specific updates, filterable by thread ID.
• Persist subscriptions and deliver verified, signed HTTPS callbacks per the MCP Events spec.

Related: #18490 (MCP protocol negotiation)

Moved from #19480 per maintainer request.

[daviesayo]

+1, with the current code and spec state attached, since the path here is shorter than it looks.

Use case. An agent drives T3 through the T3 Connect /mcp URL: it launches threads with t3_thread_launch, then has to learn when each run finishes. Today the only way is to hold t3_thread_wait open or call t3_thread_read/t3_thread_list on a timer. For runs that take an hour, that is either a blocked agent turn or repeated tool calls that cost tokens. A client whose turn has ended (ChatGPT, a cron-woken agent) gets no signal at all.

What the code does today (main @ 3962ae8)

• Transport. /mcp is Effect's McpServer.layerHttp pinned to one revision, 2025-06-18 (McpHttpServer.ts#L861-L866). Remote agents reach it through the environment's tunnel hostname. The relay Worker does not proxy MCP traffic (t3-connect.md#L4-L6).
• No server push. apps/server/src/mcp registers no MCP resources and sends no notifications/* messages. In effect 4.0.5, layerHttp answers GET /mcp with 405 (McpServer.ts, around line 1814), so a 2025-06-18 client has no standalone stream to receive anything on. The runtime also advertises resources.subscribe only when there is no HTTP request (internal/mcpRuntime.ts, around line 548), so over HTTP it is off.
• t3_thread_wait. Defaults to 10 minutes and caps at 60 (OrchestratorMcpService.ts#L102-L103, #L2647-L2668). On the server side it is already event-driven: it wakes on the thread's run.updated events instead of polling (ThreadManagementService.ts#L930-L940). The cost sits with the client, which must keep one HTTP call open for the whole wait. T3's own Claude adapter raises the MCP tool timeout to 65 minutes because Claude Code otherwise aborts HTTP MCP calls at 60 seconds (ClaudeAdapterV2.ts#L1233-L1238). Outside agents don't get that setting.
• Existing event paths are the wrong direction. Relay hooks (/v1/hooks/...) carry inbound webhooks to scheduled tasks. Agent activity goes to APNs for people's phones. Neither tells an outside agent that a run ended.

What the MCP spec offers

Mechanism	Status	Fit
subscriptions/listen with resourceSubscriptions → notifications/resources/updated	Core in 2026-07-28 (current). Replaces resources/subscribe and the GET stream.	Model each thread or run as a resource URI. A client listens on that URI and re-reads it when notified. Still needs a held stream.
Tasks extension (io.modelcontextprotocol/tasks, SEP-2663, Final)	Extension. The experimental Tasks in 2025-11-25 moved out of core.	tools/call returns a task handle. The client polls tasks/get. The server MAY push notifications/tasks over subscriptions/listen. Fits delegate_task/t3_thread_send better than a new resource model.
SEP-3415 Events Extension (io.modelcontextprotocol/events)	Open PR, not accepted.	events/list, plus poll, stream (events/stream) or webhook (events/subscribe, signed per Standard Webhooks). ChatGPT already ships the webhook mode of the draft. This is what the post above proposes.

Suggested order

1. Offer 2026-07-28 on /mcp. effect 4.0.5 already ships McpProtocol.v2026_07_28, and layerHttp serves subscriptions/listen on it unless allowSubscriptions: false. This also fixes [Bug]: Codex 0.160 agents get no T3 Code MCP tools: /mcp answers server/discover with HTTP 400 #16067, and fix(mcp): negotiate MCP 2025-11-25 so clients see invalid-argument errors #18490 covers the 2025-11-25 half.
2. Expose runs as subscribable resources. For example t3://threads/{threadId}/runs/{runId}, which reads the same status as t3_thread_wait. Emit notifications/resources/updated from the run.updated stream the wait already consumes. This uses only core spec. A client that holds one stream learns about every run it cares about without a blocking tool call.
3. Add an opt-in signed webhook for clients that can't hold a stream. Shape it after SEP-3415's webhook mode (Standard Webhooks signing, subscription TTL), so it lines up with what ChatGPT verifies today. Ship it behind a flag until the SEP settles. Feature: configurable outbound completion webhook for turn/thread terminal events #6933 asks for the same outbound callback with a configured URL.

Open questions

• Where does webhook delivery run: on the environment, which may be offline or asleep, or in the relay? The relay already stores per-thread agent activity for mobile push and queues inbound hooks while an environment is away, but only when the user enables mobile activity publishing.
• Payload: status only (thread, run, outcome), or include the last assistant message? Status only keeps transcripts off third-party URLs.
• Should a subscription be scoped to threads the OAuth client launched, or to any thread the grant can read?
• Should t3_thread_launch/t3_thread_send return the resource URI so a client can subscribe without building it?

[chrisohearn]

+1 from a second production use case, with probe results from the current nightly.

Setup. Two ChatGPT Dots dispatch engineering work into T3 through the /mcp URL (t3_thread_launch / t3_thread_send / t3_thread_read). This works end to end today: a Dot launched a T3 root that landed a PR and reported back, with no human relay.

Gap. The Dot can't be woken when a T3 thread it owns finishes, fails, or needs input. The only supported inbound route ChatGPT documents for Dots is MCP Events. Without it, every follow-up turn needs a human message or polling.

Probe (0.1.1-nightly.20261018.3335). initialize with protocolVersion: "2026-07-28" is answered with 2025-06-18. Advertised capabilities are logging, tools.listChanged and completions; there is no events capability.

Related finding that affects anyone wiring Dots to T3. Dot tasks run as a ChatGPT cloud agent that reaches the machine through codex exec-server --remote …. That client sends the server's configured static headers but never the machine's stored OAuth token, so /mcp returns missing_bearer_token until an MCP-issued token is placed in http_headers. Tokens from t3 auth session issue are rejected by /mcp (unknown_or_expired_token). If MCP Events lands, a long-lived or refreshable MCP credential for these clients would make the setup much less fragile (today's are 30-day, non-refreshable).

Minimum useful events for us: run completed/failed and runtime-request (input needed) on threads the subscriber launched, filterable by thread ID, matching the proposal above.

[fitzies]

+1. Until this lands, I've been using a small watcher on my own box as a stopgap: t3-wake (MIT).

It runs next to T3 as a systemd user service, watches the runs of threads my orchestrator launched, and sends a signed webhook when a run completes, fails, or needs input. I use it to wake a Grok Bot agent that drives T3 through /mcp, so it can pick up results without holding t3_thread_wait open or polling. The payload is status only (thread, run, outcome); the agent reads the thread itself.

One caveat: if a run ends while a background command or subagent is still going (#15099, #17625), the watcher sees it as finished, and a later wake from that background work doesn't start a new run. I work around it by telling threads to finish their checks in the same run.

Happy to retire it once MCP Events or the outbound callback in #6933 ships.

[yoonpooh]

+1. Please add native MCP Events support for ChatGPT and other external agents.

I use T3 Code on macOS and have connected it to ChatGPT as a cloud MCP plugin through T3 Connect with OAuth. The workflow I want is straightforward:

1. Ask ChatGPT to start a task in T3 Code.
2. Let the ChatGPT turn end while T3 keeps working.
3. Automatically wake ChatGPT when the task completes, fails, or needs my input, so it can read the result and report back.

Holding t3_thread_wait open or repeatedly checking thread status makes this harder than it should be. A persistent event subscription would make the cloud connector much more useful.

The minimum useful events for me are completion, failure, and input/approval requests, filterable by thread or run ID. A signed webhook with a status-only payload would be enough; the agent can fetch the full result through MCP afterward.

I also checked the installed 0.1.1-nightly.20261019.3360 server bundle: its /mcp transport is configured with protocols: [v2025_06_18], and I found no events/list, events/subscribe, or events/unsubscribe implementation there.

Please consider supporting this directly in T3 Code so external agents can follow long-running work without polling or requiring another human message.

[feldrok]

I opened #22595 as a concrete version of the webhook half of this, so there is something specific to say yes or no to. It does not add events/subscribe: that needs 2026-07-28 plus custom JSON-RPC methods that McpServer in effect 4.0.5 cannot register yet. Instead it delivers in the SEP-3415 / ChatGPT webhook shape, so receivers keep working if events/subscribe is added later.

What it does:

• t3_thread_watch { action: "watch" | "unwatch", threadId?, delivery: { url, secret | secretRef } }, plus a watch option on t3_thread_launch that registers the watch before the thread exists.
• One Standard Webhooks POST per change: run completed or failed, a question (including request_secret), an approval, and ended when the thread is settled, archived or deleted. The body is status only (threadId, title, kind, runId); the agent reads the thread itself.
• A reactor beside PullRequestWatchReactor that uses the phases mobile alerts use. The event kinds follow Home's watches in feat(home): add Home, an agent that manages threads across your machines #15975.

On the open questions above:

• Delivery runs on the environment, not the relay, so a machine that is asleep sends nothing and changes made while it is down are not replayed.
• The payload is status only.
• A watch can target any thread the caller may write to, not only threads it launched. Happy to narrow that.
• There is no subscription TTL yet; a watch lasts until it is unwatched, the receiver answers 410, or the thread ends.
• On the background-work caveat above: a run that completes while a subagent, monitor or background task is still going is not reported until that work ends, as with mobile alerts. A plain background command does not hold the completion, again matching mobile alerts.

I know a feature needs a decision on direction first, so please treat the PR as a proposal. I'm happy to reshape it or close it.

[matt-o-matic]

I'd like a maintainer decision on the direction and scope below before opening a PR. A reviewed implementation is ready, and I can reshape it or drop it.

Problem. An outside agent that starts work through /mcp can't find out when that work finishes, fails, or needs a person. It has to hold t3_thread_wait open or poll. Several people in this thread run external watchers to work around it.

Field testing. This has been tested in a live environment with a ChatGPT dot, with events delivered successfully. It's based on a working solution that has been running on a four-machine fleet for more than 30 days.

Proposed scope: native MCP Events with webhook delivery, in the shape ChatGPT already supports (OpenAI docs).

• /mcp keeps 2025-06-18 and adds 2026-07-28. On the new revision, server/discover advertises events, and events/list, events/subscribe and events/unsubscribe work on the same authenticated endpoint as the tools.
• There are two events, both limited to root threads, with project and thread filters:
  • t3.run.finished: a run ended completed or failed. Interrupted, cancelled and rolled-back runs and automatic idle compactions are never reported, and a completion waits while background work holds it.
  • t3.input.requested: a question or approval is waiting. It carries the request id and the timeline item id that t3_thread_read accepts. The event doesn't authorize answering anything.
• Payloads carry ids and the thread title, not transcripts, error text or secrets.
• A subscription belongs to the OAuth client session that made it. Revoking that access stops delivery. Agents inside T3 and linked environments can't subscribe.
• Transitions come from a fold over committed orchestration events in sequence order. Each one is recorded once, at the event that made it true. A subscription only gets transitions committed after it was activated. On first start the fold seeds open work from one consistent read, so nothing historical is sent.
• Delivery comes from the T3 server, so the client can disconnect after subscribing:
  • A signed challenge verifies the callback first.
  • Requests are signed with Standard Webhooks.
  • Retries are bounded, from a persisted outbox.
  • Event ids are stable, so delivery is at least once and receivers deduplicate.
  • Callbacks must be HTTPS to public addresses, checked at every connection, and redirects are refused.
  • Callback secrets are encrypted at rest.
• No new agent tools, so the agent context budget doesn't change. No UI.

Two choices I'd like you to confirm.

1. Effect 4.0.5's McpServer can't register custom JSON-RPC methods or advertise a top-level events capability. The patch adds a small authenticated shim on POST /mcp for events/* and the discovery capability. Is that acceptable until Effect supports it, or would you rather wait?
2. Error codes follow the OpenAI page (-32015 for a failed callback). The design sketch renumbered them to -32023–-32027 on Oct 8. Following ChatGPT seems right for now; the codes live in one table.

Size. About 3,500 lines of server code (most of it the fold, the subscription service and the hardened sender), plus about 4,000 lines of tests, and a new migration.

Out of scope: poll and stream delivery, replay cursors (cursor is always null), gap/terminated envelopes, and any UI.

This differs from #22595, which was closed for missing approval. That PR added a T3 tool with its own callback shape; this one uses the MCP Events methods, so ChatGPT and other MCP Events clients can subscribe directly.

Models used: Claude Opus 5.5, GPT-6.1 Sol and GPT-6 Astra.

Is this direction and scope approved for a PR?

[Conte777]

I tested this use case with Dot on macOS. It works through a separate bridge, without changing T3 Code or maintaining a fork.

The path is:

T3 Code → local bridge → MCP Events → Dot

The bridge uses a read-only WebSocket subscription to T3 Code’s orchestration.subscribeShell. It exposes events/list, events/subscribe, and events/unsubscribe through OpenAI Secure MCP Tunnel.

In the end-to-end test:

• Dot created a subscription through the tunnel.
• Callback verification succeeded.
• A real T3 run completion reached Dot and triggered a response without another user message.
• A user-input request and a waiting state also reached Dot.

The waiting event had no pending runtime request, so this does not prove a blocking question flow. Failed runs, delivery retries, and Mac sleep recovery remain untested.

The bridge stores checkpoints and deduplication state in SQLite. Restart recovery was tested.

My goal is to let Dot coordinate multiple T3 coding sessions. Events wake Dot; it then uses the existing T3 MCP integration to read context and decide what to do next.

Native MCP Events support would remove the need for this separate bridge and its dependency on T3’s internal WebSocket interface. This experiment confirms that the Secure MCP Tunnel → MCP Events → Dot part works for my account.

[MineraleYT]

+1, with one more use case: an always-on personal agent (Hermes, running as a systemd service) that I drive from Telegram. It works in short turns, so it can't hold t3_thread_wait open for a long run. Today it needs a separate poller on t3_thread_read just to tell me "the thread is done, want a follow-up or a PR?".

What I need from this is the thread id, status (completed / failed / waiting for input) and the thread link, for threads the agent itself launched or messaged. A per-thread subscription or callback with a signing secret would cover it. An environment-wide stream isn't needed.

[rafahenrique-prime]

Hi T3 Code team,

I’d like to add my support for this direction. My use case is using ChatGPT Work to supervise Claude and Codex agents working in T3 Code. Once Work hands off a task, it needs a dependable signal to resume when the run completes, fails, pauses for approval or other human input, or is interrupted/stopped. Polling or holding t3_thread_wait open makes that workflow fragile and adds unnecessary calls.

A secure, signed, status-only webhook for those events would be immediately useful; eventual alignment with native MCP Events would also give ChatGPT Work and other external MCP clients a standard subscription path. The thread-watch proposal in #22595 looks like a practical step toward that goal, with interruption notifications especially important for a supervisor to distinguish a stopped run from work that is still in progress.

I understand this is a new feature and requires maintainer approval. Could you advise whether this scope fits the project direction and what approval or narrowing would be needed before implementation proceeds?

Thanks for maintaining T3 Code.

[Sadrak2017]

Could out-of-order delivery be an explicit acceptance case alongside deduplication? For example, a retry of run A's finished event arrives after run B has requested approval in the same thread. A stable event ID identifies the duplicate but doesn't tell a supervisor which state is current. In the agent-monitoring work we're doing on Sinaps Studio at SinapsData, I'd treat the callback as a wake-up hint and re-read current state under the subscriber's access before acting. Including an orchestration sequence with the run/request IDs could make that distinction testable without sending transcript content.