Repository navigation
Plugins by repository URL: a runnable, isolated agent-proxy prototype #23574
Replies: 10 comments
|
@t3dotgg, in today's stream, you mention how you are trying to collect the plugin ideas before you decide how you want to implement it. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. There is now a second installable external consumer of this prototype: MCP Manager, released as v0.3.0. It implements the shared-server and project/account configuration use cases discussed in #14118 and #7062:
This requires the prototype plugin host; it does not install into stock T3 Code. The compatible host is published on t3/create-plugin-system, with pinned settings-page source at cbf59e9adc. On that build, install The host changes add a generic per-session MCP contribution and a bounded HTTP response-acquisition timeout for long MCP calls. Native protocol translation, authorization and worker supervision remain host responsibilities. The external plugin owns the server-selection policy, OAuth, refresh/reconnect/disconnect behavior and portable settings view through the public SDK. That is the useful part of the plugin proposal: someone with this feature need can publish and maintain an optional repository, and users can try it without asking T3's maintainers to own that feature's settings and OAuth implementation. The host contract still needs review and maintenance; this is a concrete second consumer to evaluate that boundary, not a claim that extensibility is free or that every feature should become a plugin. Actual UI captures, using synthetic projects and accounts: Plugin lifecycle controls stay in Settings → Plugins, while each contributed settings page appears under Extensions:
Environment-wide defaults and project-scoped OAuth definitions, enabled for Claude, Codex and Grok:
Two projects connected to the same test MCP endpoint with separate OAuth accounts and independent switch/disconnect controls:
These are refreshed, unaltered Linux web-client captures of MCP Manager v0.3.0 on host Validation includes 13 plugin behavior tests and Linux/macOS/Windows CI on the released commit, public repository installation and the v0.2.0 → v0.3.0 update with configuration/secret preservation, removal, and OAuth integration through packaged and Linux standalone supervised workers. Grok-specific checks also passed: 19 focused tests, project/provider-instance policy and OAuth worker checks, and the installed Grok 1.0.70 handshake advertising HTTP/SSE. A fully authenticated native Grok session or paid turn is not claimed. Managed OAuth currently supports Streamable HTTP; legacy SSE keeps static headers or an external bridge, and stdio servers retain their own authentication. Pi remains unsupported. This addresses the management portion of #32133, not MCP Apps' scoped approval grants or repeated confirmation dialogs. Those authorization semantics still need a host/provider decision. OAuth versus MCP App consent (clarification): A project's OAuth connection is separate from a widget's permission to run a tool. MCP Manager v0.3.0 has no remembered app/tool-consent cache. A completed account switch or reconnect rotates that definition's private route credential and clears its transport sessions; disconnect removes the local OAuth connection. A fresh check against the released bundle confirmed that old credentials get 403 and an old session paired with a new credential gets 404, while an unchanged project's session and ordinary token refresh continue working. This used a local OAuth/MCP fixture, not a rendered widget or a real SaaS account. Existing provider sessions must reconnect/restart to receive a new route credential. Labels remain user-entered, not verified account identities. The host still confirms each non-read-only widget tool call; identity-bound remembered grants and their revocation remain proposed host behavior, not a feature delivered by this plugin. I'd especially welcome feedback on whether this second consumer demonstrates an appropriately small shared seam, and which part of that seam maintainers would narrow before considering a plugin host. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Another installable consumer of this proposal is now available: Worktree Environments, released as v0.1.0. It addresses the pre-removal resource-cleanup use case in #14804: a worktree can own a database, container, or other resource outside its directory, and its cleanup script needs to run while the checkout and its local state still exist. Install This needs the prototype host fork, not stock T3 Code. The maintained host branch is now rebased onto upstream main The behavior is:
For example, a project can commit this {
"version": 1,
"hooks": {
"worktree.created": [
{ "id": "setup", "command": "node", "args": ["scripts/worktree-env.mjs", "setup"] }
],
"worktree.removing": [
{ "id": "cleanup", "command": "node", "args": ["scripts/worktree-env.mjs", "teardown"] }
]
}
}Commands receive Dedicated settings page:
A deliberate cleanup failure is reported in the owning thread while the checkout is preserved:
Settings, cleanup failure and successful retry recording. These captures use synthetic development state on compatible host The plugin's released commit passed Linux/macOS/Windows CI, with additional native macOS fleet checks. The current host passed its changed-code check (1,591 tests and 42 affected-package typechecks), server/web builds, normal and Linux standalone worker loading, and public repository-URL install/update/removal checks. Native desktop/mobile GUI verification is not claimed. Scripts need to be idempotent. Disabling or uninstalling the plugin stops its hooks, so remove worktrees that own external resources first. Deletion outside T3 cannot emit these lifecycle events. Plugins remain trusted same-user code in supervised processes, not hostile-code sandboxes. This is another concrete reason to consider the shared host: project-specific environment automation can live in an independently released repository, while T3 maintains generic lifecycle, permissions, process supervision and thread failure-reporting boundaries. I'd welcome feedback on whether those boundaries are appropriately small for this use case. |
|
NOTE: This comment was left by claude-fable-5-2 unknown-effort on behalf of Dj Gilcrease. Another installable consumer of this proposal is now available: Rehome, tagged v0.1.0. It implements the request in #31077: move a thread that has already started to another machine, with its conversation and the work that has not left the first machine yet. Install This needs the prototype host fork, not stock T3 Code. The host branch has what Rehome needs from 8844a8a483 on, based on upstream main What it looks likeA thread on
The confirmation picks the destination and says what stays behind:
The result. The original is archived, and its page closes, so the dialog is hosted outside the thread:
The same thread on the Mac, with its conversation, its branch, and its uncommitted changes (
What a move doesIt is a copy followed by an archive, as #31077 proposes. Nothing is deleted, so a move that fails loses nothing.
The copy's first message starts a new provider session that is handed the conversation, through the same path T3 already uses for imported history. Files Git ignores, attachments, terminals, previews and the provider's own session do not travel. Threads with subagent threads, and projects without a Git remote, cannot move yet. What the host neededThe plugin imports only the SDK and
Rehome also has a headless Verification
Not claimed: the mobile rows typecheck but were not run on a device, and no move in these runs interrupted a turn that was still running; that path is covered by a test with a stand-in host. I'd welcome feedback on whether a plugin-contributed item in the thread details, and a client-carried step between environments, are seams maintainers would accept in a plugin host, or would narrow. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Sandboxes is another installable consumer of this prototype, released as v0.1.1. It implements the on-demand environment request in #18019. Install Each sandbox runs its own full T3 server. Clients connect directly to it, so chat, terminal, Git, and the agent harness use the existing remote-environment paths. Docker and Boat are built in; an external executable or HTTPS broker can supply other providers. Launch from the composerChoose New sandbox, select a provider profile and pushed base commit, and send. Provisioning and the first message run on the controller, so closing the client does not cancel them. Each client discovers the environment and receives its own one-time pairing token; the initiating client opens the guest thread.
Status and lifecycleThe plugin contributes small statuses in the sidebar and thread pane, plus Stop/Resume and an extension page for profiles, policy, Keep awake/Clear, and Pin/Unpin.
Defaults are a 15-minute idle stop, 60-minute waiting grace, two-hour unattended lease, and 12-hour continuous-run cap. Boat holds an independent provider deadline. Docker's timers require the controller to stay online. Estimated runtime/cost appears in Usage; configured caps refuse new allocations or resumes. A controlled stop attempts to pause/checkpoint work and exports complete transcripts, including archived threads. Export failure blocks that stop; an independent provider deadline still applies. Stop keeps disk and the client's cached thread. Automatic deletion requires retained history and clean, pushed worktrees, or a successful Rehome copy; otherwise it stays stopped. Explicit deletion requires data-loss confirmation, and Pin prevents automatic deletion. Rehome is optional. When installed and configured on both sides, Sandboxes discovers its pull/status commands to copy the thread home. Without it, transcript retention still works.
Extension settings and transcript retention
Host boundariesThe new seams are bounded managed-environment advertisements, launcher views that receive a draft and return a durable receipt, thread status/activity, and a guard against uninstalling a controller that still owns resources. They are on the same host branch as Agent Proxy, MCP Manager, Worktree Environments, and Rehome. The plugin imports no T3 server internals and adds no cloud-provider code to T3 itself. Evidence and limitsThe screenshots show real Docker provisioning, a pushed checkout/worktree, controller-owned first send, automatic pairing, retained history, and a controlled stop. The conversation uses T3's free Replay (dev) fixture through its real adapter and orchestration. Its simulated tool output is not evidence of a paid model or actual code edits/tests. The plugin's 20 tests and CI pass, including recovery, limits, retention failures, and the safety script after bundling. The host passed 294 focused tests and its scoped checks. The screenshot pass caught a narrow-pane layout issue, now fixed on the shared branch. Packaged Docker stop/resume and Boat CLI lifecycle checks were also run. Guest images must already contain the matching T3 host, agent tools, and Git access. First-message launch is text-only. Mobile is implemented/typechecked but was not run on a native device. Daytona's built-in driver, T3 Connect reach, and moving/forking existing work into a sandbox remain later work. I'd welcome feedback on whether managed-environment advertisements and a plugin entry in the environment picker are host boundaries maintainers would accept for this use case. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Theo Hates Notifications is now released: repository · v0.1.2, prebuilt bundle and evidence. This lets each environment route notifications to Slack, ntfy, generic JSON webhooks, Discord and Gotify, as well as in-app toasts, system alerts/sound and T3's existing mobile delivery adapter. For example, send input/approval requests to ntfy, completions to Slack, and failures for one project/provider account to a webhook. Optional integrations, filters, secrets setup, queueing and retries live in the external plugin; the host exposes generic committed notification, client presentation and native delivery contracts. Install Installation changes no builtin setting and creates no route. External destinations add channels. Client presentation changes only after explicit routing selection; disabling/removing the plugin restores builtin ownership. Ambiguous client owners fall back to builtins, and native refresh reuses existing relay deduplication. Extensions remains hidden when no active plugin contributes a settings page. The audit goes beyond completion/input/approval: failure, usage limits, guest requests, review-guide outcomes, operational toasts/dialog alerts, system/mobile notifications, audio, badges, preferences, focus/reconnect/hidden-thread suppression, actions/deep links, Android ongoing notifications, iOS live activities/widgets and accessibility/capture feedback are mapped in the parity inventory, with exact source references and verification receipts. Existing features stay active; this PoC performs no migration. Host requirement: djgilcrease/t3code Verification includes 1,962 focused host tests, 10 plugin behavioral tests, Linux/macOS/Windows CI, actual public-tag install/update/removal with secret persistence, fake Slack/ntfy/webhook endpoints, real web notification actions and a locally built Android development client. Replay fixtures used no paid models. The input notification → Open thread video shows timing and navigation; destination setup video shows the portable UI.
Limits: the Android image is a local development-catalog notice, not relay push. Real relay push, iOS ActivityKit/widgets, macOS/Windows OS presentation, every provider account and assistive technology/audio output remain unverified. Haptics, confirm/prompt decisions and SnapShot capture feedback remain feature-owned and are not externally routable. Client notices/reviews need an open client. HTTP delivery is bounded and at least once; receivers may need to deduplicate after an uncertain request outcome. Native dispatch is not device receipt. These boundaries are explicit in the inventory, rather than a claim of fully verified replacement parity. All screenshots and videos above are immutable public release assets. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Git History Explorer: a second kind of portable data-view consumerdigitalxero/t3-git-history now has a stable v0.1.0 release, addressing the repository-history request in #6943. This requires the prototype host fork. It was verified against djgilcrease/t3code at Paste this into Settings → Plugins on that host: Then open Settings → Extensions → Git history, choose the owning environment, and enter its repository/worktree directory or a thread ID from that environment. The thread form resolves its project/worktree through the public SDK. The view adds repository-wide topological history across HEAD, local branches, remote-tracking branches and tags. Each row shows its direct parents, ref labels, subject, author and author date. Inspect a commit for its message and changed files, follow its parents, choose a merge parent for comparison, and open a file's textual patch with navigation back to its commit. This complements the existing per-commit branch-comparison feature. There are no checkout, rebase, fetch or other repository-writing operations. The first release uses an explicit commit → parents table, not colored graph lanes. It uses a portable text patch view rather than linking into the builtin diff pane. Git queries, parsing and feature behavior live in the external repository; there are no imports of server internals. The generic host seam is a bounded command result that replaces only the calling panel, plus a preformatted text block. Browsing state stays with that client, so two clients do not overwrite each other's navigation. The host still renders finite data using its own web/desktop/mobile components; no arbitrary client bundle was added. Evidence: real GitHub URL install, disable/enable, managed-package removal and reinstall, and a current-tag update check passed on the integrated Linux host. The installed Browser-panel client paged the real T3 repository and inspected commit files and patches. MCP Manager v0.3.0's older portable view rendered concurrently. The normal packaged worker loaded the self-contained installed bundle outside the checkout with no
Commit and merge parents · Textual patch · Before installation Actual limits: 15 commits/page through offset 10,000; 10 seconds and 8 KiB output per Git query; 20 changed files/page; patches capped at 8,000 characters with explicit truncation. Oversized metadata/file lists fail visibly. Supported unusual UTF-8 paths use NUL-delimited parsing and quoted labels; invalid UTF-8 filenames are unsupported. All-ref paging can shift during concurrent branch changes; selected refs are pinned. Shallow clones expose available history only. Native Electron/mobile GUI, relay/tunnel/multi-environment runtime, SEA packaging and a later-version update transition were not exercised. Host CI's inherited budget failure and queued Blacksmith jobs were not green; Dj merged the host PR, and the focused/build evidence is not full-host acceptance. The tagged repository ships the matching install manifest, built ESM bundle, MIT licensing and Effect attribution. This is a small read-only first release intended to prove the generic navigation seam with a useful independent consumer. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Shared Project Memory is now available as an external plugin, released as v0.1.0. It addresses the provider-neutral learned-knowledge request in #15858. Install This requires the prototype host fork and does not imply upstream approval. Minimum verified host: djgilcrease/t3code at Agents discover Users can inspect, edit, delete, clear and export from the portable settings view. Recall is explicit, lexical and bounded: default five results/8,000 characters, maximum twenty/20,000, with at most 500 facts per project. Private Project Notes remain distinct: this plugin never reads them and never automatically supplies memory to an agent. There is no transcript scraping or prompt injection. I investigated both veqlite and rag-lite-ts, including their current source and practical persistence/vector experiments. For this small lexical use case, neither justified its embedding/native/WASM and recovery machinery. V1 uses atomic per-project JSON snapshots with no model downloads or API cost. The durable storage decision records pinned source, dependencies, licensing, the veqlite Node-adapter failure, successful RAG-lite persistence/index experiments, and the tradeoffs of the chosen backend. Evidence: the plugin's required policy and operation/build CI passed on Linux, Windows and macOS, including the exact merged release commit. The combined host passed 34 focused tests and built its normal packaged server. Real repository-URL installation selected and pinned the stable tag; worker restart, disable/enable, project isolation, corrections/export, forget, removal and managed-data deletion passed. The tagged bundle, extracted archive and unauthenticated public download loaded in the normal packaged worker without a plugin dependency install. Linux Browser-panel verification exercised the inspector, enable, remember, correction/provenance, visible export and clear/disable. Release assets include the built module, matching manifest, minimal archive, checksums, verification receipt and before/after captures. Plugin delivery PR #1. Actual limits: no cross-machine sync, semantic search, automatic deduplication or import. Independent environment/project records stay separate even for the same Git repository. Exports are copyable, paginated JSON text; the inspector selection is shared across clients, while each form keeps its explicit destination. Disabling project access retains user-inspectable/exportable/deletable data; clearing deletes entries/history and disables access; plugin removal deletes managed data. Already exported or recalled copies cannot be withdrawn. Native Electron/iOS/Android, Linux SEA and live remote/tunnel/provider turns were not run; OS CI is not proof of those surfaces. The host PR was merged by Dj with its inherited budget failure/queued Blacksmith jobs known, so the local host proof above is not a claim of green hosted host CI. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. Private Project Notes is available as an external plugin, released as v0.1.0. It responds to Ideas #9353, extended at Dj's request to multiple text, checklist and image notes. Install This requires the prototype host fork and does not imply upstream approval. The pinned host requirement is djgilcrease/t3code at Notes are ordinary Markdown with stable frontmatter, local image assets, and small identity/revision/deletion metadata files. They can be edited in tools such as Obsidian; retain the metadata. External edits, renames and deletions import when the panel opens or Refresh runs, including changes made while the host was stopped. The default directory is exactly Every participating machine persists its synchronized files, using its configured directory or that default. There are no memory-only replicas. To connect projects safely, copy the source's shared identity into an empty destination project's settings, then choose Sync notes… and a connected environment. Raw local project IDs and repository names never silently merge projects. The open client carries bounded, bidirectional sync commands and image data between environments. Concurrent edits remain visible as conflict versions; tombstones prevent deleted notes returning. Offline copies survive restart and reconcile on the next explicit sync. These are private user-authored notes. All plugin commands have agent access disabled, and host-level denial was tested. The plugin contributes no MCP servers or provider/prompt hooks. It is separate from Shared Project Memory, and neither automatically reads these notes nor injects them into prompts. Evidence: required plugin policy/build/test CI passed on the exact release commit
Actual limits: sync is user initiated through an open connected client, with explicit project linking; there is no continuous cloud sync or background filesystem watcher. Limits are 200 note IDs including tombstones, 20 concurrent versions/note, 16 KiB bodies, 64 KiB PNG/JPEG/GIF/WebP images and 32 MiB project data. Old directories, tombstones and assets are retained rather than automatically deleted. The two-environment sync test is a plugin harness, not a live remote-machine session. Native Electron/iOS/Android, live relay/tunnel operation, SEA packaging and an update to a later plugin version were not exercised. Desktop shares the web renderer; mobile passed affected static/React Compiler checks. Dj merged the host PRs while inherited/queued hosted checks were unresolved; the local evidence does not claim green full-host CI or upstream acceptance. MIT notices for the SDK snapshot and bundled Effect are retained. |
|
NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease. From Issue is now released as v0.1.0, implementing Dj's project opt-in and issue-linked thread flow for Ideas #30981. This requires the prototype host fork and does not imply upstream approval. Minimum verified host: djgilcrease/t3code at Paste this into Settings → Plugins on that host: Enable From Issue under Settings → Projects → New threads. Its initial source dropdown has Source Control and Linear.
The host adds reusable project-settings, association, navigation and reference boundaries. Tracker adapters, Linear auth/consent, issue data and persistence live in the external repository; the plugin imports no server internals. Project-specific From Issue under New threads:
Two linked issues before the first send, on the production-packaged host:
Clicking an issue loads its current description inside the client:
Evidence: plugin PR #1 merged with both required checks green. Scoped host checks, worker IPC and turn-context regressions passed. The production-packaged Linux host installed the real repository URL at the stable tag, loaded the exact committed bundle, and passed update detection, disable/re-enable with byte-identical association data, removal and clean reinstall. The real web client exercised draft selection, saved links, in-app loading, removal and clearing; a free Replay turn exercised draft promotion. Live public GitLab reads/parsing also succeeded. The release includes before/after captures, checksums, a verification record and public-download/artifact smoke results. Actual limits: live Linear access was not tested; its consent, pagination, workspace identity and permission-loss flows have deterministic tests. Android automation was occupied by another session, which was left untouched; native Android/iOS and Electron shell UI are not claimed. One live Linux environment was tested. Tracker calls run on the owning server; links and consent remain environment-local and are not transferred by thread rehoming. Source responses are bounded to 128 KiB; GitHub search exposes up to 1,000 matches and GitLab accepts 100 pages. There is no Jira adapter, backlog board, epic rollup, tracker writeback, or issue comment/attachment ingestion in this release. The update check found the current version; no version-to-version upgrade is claimed. The fork's full hosted server CI remains queued for a Blacksmith runner, and GitHub reports no runners registered on the fork. The local focused checks and isolated runtime evidence above are separate from that unavailable hosted result. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
A working plugin prototype, starting with a feature that should not need to live in core
The agent proxy proposed in #16677 is useful, but it also asks T3 maintainers to own OAuth flows, account pooling, quota APIs, routing strategies, and several model protocols. Those change independently of T3's conversation UI and orchestration.
I built an environment-owned plugin host and moved that unmerged feature into a separate public repository. The proxy installs from its GitHub URL and contributes its settings, Usage view, commands, streaming HTTP endpoint, and supported provider-launch routing through the same public SDK another plugin would use. No existing builtin feature was rewritten as a plugin.
This is a runnable prototype for discussion, not a request to merge a new platform without agreement on its boundaries. There is no upstream implementation PR.
mainat8d3b061121fe65669d5d43d011b48cd3027a4108.What the user does
Open Settings → Plugins, choose the environment, and paste:
Settings-page update (2026-11-10): Plugins now contribute their own entries under Settings → Extensions. Configure the proxy at Settings → Extensions → Agent proxy; MCP Manager and Worktree Environments have separate pages there too. Settings → Plugins handles installation, updates, enable/disable, removal and crash limits. Extensions is hidden when no active plugin contributes a settings page. The current releases require this updated PoC host; there is no older-host UI fallback.
The host finds the highest stable semantic-version tag, checks out the selected commit, validates the plugin package, and starts it. There is no marketplace, central catalog, plugin account, or npm installation step. Plugin authors ship their built entrypoint and dependencies in the tagged repository. Package scripts, Git hooks, and submodules are not executed during installation.
Updates are checked daily while the environment runs, or through Check for updates. Checking does not execute a new version. The user explicitly chooses Update. Disable keeps data; Remove unregisters the plugin and clears its managed package, saved data, and namespaced credentials. Manually registered source folders are preserved.
GitHub, nested GitLab, and self-hosted HTTPS Git URLs use the same Git-based mechanism. Private repositories use credentials already available to Git on the environment; tokens do not belong in the URL. Live install/update testing used GitHub; GitLab URL/tag behavior has focused tests.
These current screenshots use host
cbf59e9adcwith Agent Proxy v0.2.0, MCP Manager v0.3.0 and Worktree Environments v0.1.0 in isolated Linux web-client state. The crash, Usage and tag-update captures and videos below remain historical v0.1.2 verification evidence; their older settings layout is not the current UI.Install, remove, reinstall, disable/enable, and configure the restart limit — video
Why add a host at all?
The benefit is giving independently maintained features a place to connect without a fork or another feature-specific RPC/UI path in core. A proxy is a demanding example: it needs long-lived state, secrets, HTTP streaming, background quota refresh, UI, and launch integration together. A one-off MCP tool or an external daemon can supply parts of that, but does not by itself give users one environment-owned installation and management flow across T3 clients.
Core maintains a small set of connection points. The plugin author maintains the external service's behavior and release cadence. A broken optional integration can be disabled or removed independently. Users who do not install a plugin do not run its worker or load its feature dependencies into the server process.
This also gives experiments an exit path: prove usefulness as an external repository before deciding whether a capability belongs in the default product. It does not mean authentication, durable orchestration, rendering, or every existing feature should move out of core.
The contract implemented today
/api/plugins/<id>/, with plugin-owned authentication and cancellation.A repository contains a versioned
t3-plugin.jsonand a built JavaScript module implementingT3Plugin. The SDK describes the public contract; it does not expose server services, the database, React components, Electron IPC, or the orchestrator's decider. Too-new API versions and invalid contributions are rejected.Commands are service calls behind thin transports. The host checks the actual command's permission, rather than trusting the permission supplied by a caller. Agents discover opted-in commands through
t3_plugins_list,t3_plugin_read, andt3_plugin_run. A read envelope cannot turn a write command into a read command. Installation/removal are absent from these MCP tools; secret-bearing proxy sign-in/import/key commands are client-only.Plugin views are data. They cannot inject browser JavaScript or add work to transcript rendering. Standalone settings pages and Usage keep the client contract finite: a plugin contributes a portable data view and a navigation entry, not arbitrary React, HTML or browser JavaScript.
The implementation separates package retrieval, serialized lifecycle management, contribution validation/dispatch, and the worker protocol. There is no general filesystem/network/process capability broker to maintain: this first version explicitly installs trusted same-user code. It reuses T3's existing environment permission model for access from clients and agents.
Failure containment is part of the feature
Each plugin runs in its own OS process. It has bounded IPC and concurrent calls, a JavaScript heap limit, startup/handler watchdogs, and a supervisor. An exiting process or stalled event loop is stopped independently. After five failed attempts by default, the plugin stays stopped for that server session until explicitly retried, re-enabled, or updated. The limit is configurable per plugin, from 1 to 100; a minute of stable operation resets the failure counter.
Startup activation runs separately from constructing the environment, so a stalled plugin does not prevent T3 from opening. Plugin operations wait for initialization, which prevents a launch from silently bypassing a not-yet-ready routing hook. A stopped runtime routing hook fails the affected launch closed. Ordinary cancelled view refreshes do not kill the worker; the handler watchdog still catches a real stall.
The UI test deliberately crashed one plugin. It stopped after exactly five attempts while T3 and the healthy proxy remained usable. Changing the limit to three and retrying produced exactly three further attempts.
Crash limit, explicit retry, and continued application use — video
This is trusted-code process isolation, not a hostile-code sandbox. A malicious plugin running as the same OS user can attack files, processes or system resources. No honest implementation should promise that system-wide OOM, intentional same-user attacks, or a runtime vulnerability can never affect T3. The tested guarantee is containment of ordinary worker exits, exceptions, hangs and bounded protocol failures.
WASM could be another worker execution backend later. A V8 isolate by itself is not an OS-process boundary; keeping the process boundary would still be valuable for heap/native-runtime failures. WASM, fuel metering and an OS sandbox are not implemented or claimed here.
The external agent proxy proves the complete path
The proxy repository owns account authorization/import, private credentials, quota collection, closest-reset/round-robin/least-active selection, sticky sessions, failover, key rotation, and streaming model-protocol translation. Its routes cover OpenAI Responses/Chat, Anthropic Messages, and Google generation formats. Settings and Usage are ordinary portable plugin views.
Supported launch integration currently covers Codex agent/text-generation launches, Claude agent environment/text-generation launches, and T3-managed OpenCode. Cursor, Grok, Pi, Muse and ACP/Antigravity driver paths are not claimed to use these hooks. Supporting additional adapters needs an explicit integration and tests; a proxy supporting an upstream model protocol does not imply every T3 provider runtime is connected.
A user can also configure a verified, directly reachable remote proxy URL/key, view its account status, and disconnect it. Environment management travels over T3's normal authenticated connection. Plugin-owned HTTP routes are a different transport: a relay connection does not automatically publish them, and the prototype does not discover a remote proxy automatically.
Secrets are not returned in views. Explicit client key disclosure is masked, copyable, dismissible, and cleared after 30 seconds. The proxy's JSON uploads are bounded to 16 MiB; oversized streams are cancelled with HTTP 413. Existing provider sessions need restarting to pick up routing changes.
Proxy settings, account controls and masked credential handling — video · Remote-client control — video · Usage view — video
I also sent a real Codex request through the installed plugin: model discovery returned eight models, and inference returned HTTP 200 with a completed stream. The temporary validation account was removed afterward. This is stronger evidence than fixture-only protocol tests, but it is not a claim that all six upstream services' current OAuth/account policies have been verified live.
Updates and recovery were exercised against real tags
The actual update test caught a packaging error: v0.1.1's install manifest still declared v0.1.0. The host rejected that package and kept the working installed version. This exposed missing UI error feedback, which is now present in both client implementations. Release CI now checks the package, install manifest and built module agree.
Updating the same installation to v0.1.2 succeeded and retained its account, pool strategy, sticky-idle setting and restart limit. The failed tag was not rewritten. Activation/persistence rollback and daily/manual check scheduling also have focused tests. Package rollback does not undo a plugin's own data migrations; authors still need backwards-compatible storage changes.
Real tag-based update with preserved settings — video
What this borrows from previous attempts
I read RFC #18844 and the earlier work it links. There is substantial prior art here, and process supervision is not a new invention in this branch.
The case for this approach is a concrete external consumer, reproducible repository installation, explicit failure/update recovery, and a finite public API. It is not that every earlier design was wrong, or that a working prototype automatically settles the maintenance tradeoffs.
Which builtins could be plugins?
The full source-based audit separates capabilities possible through today's SDK from missing host boundaries. No builtin was migrated as part of this work.
I would grow the SDK only when another concrete consumer proves a missing boundary. Adding interfaces for every builtin up front would repeat the large-contract problem. The current implementation is intentionally honest about what it cannot yet replace.
Verification and remaining limits
Full commands, source pins, media provenance and exclusions are in the verification receipt. UI captures use synthetic accounts; native quota panels were hidden with the existing filter for the Usage capture. Recordings are cropped to the browser viewport and are not mockups.
The UI pass used T3's Browser panel against isolated Linux state. Native Electron-shell GUI, native mobile GUI, Windows and single-executable packaging have not been exercised. Non-Codex live OAuth/inference and relay-published proxy endpoints are also not claimed. The host checks are targeted; they are not a claim that the full T3 release/CI matrix was run.
What I would like maintainers to decide
Is a persistent environment-owned extension appropriate for capabilities like the agent proxy, beyond provider-launched MCP configuration? Are commands, portable Settings/Usage views, launch preparation and streaming HTTP a reasonable first boundary? Which additional boundary, if any, has a concrete builtin or external consumer worth supporting next?
The branch makes those choices reviewable and testable before asking to land them. I will not open an upstream implementation PR without agreement on the scope. The standalone proxy can continue evolving outside T3 once the agreed host contract exists.
All reactions