Version Packages - #1811
Open
RhysSullivan wants to merge 1 commit into
Open
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-marketing | 2785471 | Commit Preview URL Branch Preview URL |
Aug 28 2026, 09:04 AM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-cloud | 2785471 | Aug 28 2026, 09:05 AM |
Contributor
Cloudflare preview
Sign-in is Cloudflare Access (one-time PIN to an allowed email). The preview has its own database and encryption key; it is destroyed when this PR closes. |
@executor-js/cli
@executor-js/config
@executor-js/execution
@executor-js/sdk
@executor-js/codemode-core
@executor-js/runtime-quickjs
@executor-js/plugin-file-secrets
@executor-js/plugin-graphql
@executor-js/plugin-keychain
@executor-js/plugin-mcp
@executor-js/plugin-onepassword
@executor-js/plugin-openapi
executor
commit: |
RhysSullivan
force-pushed
the
changeset-release/main
branch
from
August 28, 2026 09:02
be05735 to
2785471
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@executor-js/cli@0.2.53
Patch Changes
@executor-js/config@1.7.0
Patch Changes
@executor-js/execution@1.7.0
Patch Changes
@executor-js/vite-plugin@0.0.63
Patch Changes
@executor-js/runtime-quickjs@1.7.0
Patch Changes
@executor-js/plugin-desktop-settings@1.7.0
Patch Changes
@executor-js/plugin-example@1.7.0
Patch Changes
@executor-js/plugin-file-secrets@1.7.0
Patch Changes
@executor-js/plugin-graphql@1.7.0
Patch Changes
@executor-js/plugin-keychain@1.7.0
Patch Changes
@executor-js/plugin-mcp@1.7.0
Patch Changes
#1595
8324e1eThanks @GeiserX! - Stdio MCP servers no longer inherit executor's full environmentA stdio MCP server that declared any
envat all was spawned with every environment variable this process holds. The MCP SDK already guards against that: it spawns with{ ...getDefaultEnvironment(), ...serverParams.env }, wheregetDefaultEnvironment()is a sudo-style safe-list ofHOME,LOGNAME,PATH,SHELL,TERMandUSER. Passing{ ...process.env, ...config.env }did not add to that safe-list, it overwrote it. In practice, adding one third-partynpxserver went from "this server can see the API key I gave it" to "this server also holdsEXECUTOR_SECRET_KEY, the key that decrypts every other stored credential, plusEXECUTOR_AUTH_TOKENandDATABASE_URL". The leak sat on theconfig.envbranch — the branch a credential-bearing integration takes.A stdio server now receives the SDK's safe-list, the variables declared on the source config, and one short allowlist of infrastructure variables read from the host:
HTTP_PROXY,HTTPS_PROXY,NO_PROXY(both spellings),NODE_EXTRA_CA_CERTS,SSL_CERT_FILEandSSL_CERT_DIR. Those carry no credential, no source config declares them, and a server behind a corporate proxy or an intercepting CA cannot reach anything without them — the same reasoning and the same listservice installalready uses when it bakes a supervised unit's minimal environment. The declaredenvwins on a key collision. On Windows that collision is resolved case-insensitively, because the OS treatsPathandPATHas one variable while a JavaScript spread does not: a declaredhttp_proxynow replaces an inheritedHTTP_PROXYinstead of travelling beside it, which would have left the child reading whichever spelling Windows resolved first.If a stdio server relied on some other variable arriving from the host, set it explicitly on the source's
env. That is now the only way anything beyond the lists above reaches a server, and it is the mechanism that already existed for it.Updated dependencies []:
@executor-js/plugin-onepassword@1.7.0
Patch Changes
@executor-js/plugin-openapi@1.7.0
Patch Changes
#1530
85b1955Thanks @BittuBarnwal7479! - Multipart file fields in an OpenAPI spec now accept and send real files. Amultipart/form-dataproperty typed as a binary or byte string is rewritten into the SDK's tool-file schema when the tool is extracted, so an agent supplies a file the same way it does everywhere else. On invocation those values are decoded back intoFile/Blobparts — as bare properties and inside arrays, with a per-propertyencoding.contentTypeapplied to each file part — instead of being JSON-stringified into the form body, which is what upstreams were previously rejecting. A file whose base64 payload does not decode now fails the invocation and names the field, rather than sending the file envelope as JSON.The rewrite advertises only the shapes the request encoder can deliver. Two are deliberately left alone:
$ref. Component schemas are carried through unresolved by design — the streaming compile path never materializescomponents.schemas— so a$ref'd file field keeps its declared binary string type.The rewrite reads the request schema's own
propertiesmap rather than walking every object key, so adefault,example, or vendor extension that happens to look like a binary string schema is untouched. Descriptions, titles, and nullability on the replaced field are carried onto the file schema.Updated dependencies []:
@executor-js/plugin-toolkits@1.5.38
Patch Changes
@executor-js/sdk@1.7.0
@executor-js/codemode-core@1.7.0
executor@1.7.0
Minor Changes
#1572
27cb466Thanks @GeiserX! - Irreversible cleanup now waits for the transaction to commit, and plugins can do the sameoauth.removeClientdeleted the client row and then deleted the client secret from the credential provider. The provider does not enlist in the caller's transaction and does not roll back with it, so an abort restored the client row while its secret stayed destroyed — a client that looks configured and can never authenticate again. The deletion now waits until the removal is durable and is discarded if the removal rolls back. With no transaction active it runs immediately, exactly as before.Deferring the deletion is not enough on its own. The secret is stored under a key derived from the app's
(owner, slug)identity alone, so the key outlives the row it belonged to: whoever holds that identity when the deletion finally runs owns the key. A slug registered again before the removal committed would lose the new app's secret to the old app's queued deletion — the same unauthenticatable client, reached the other way round. The deferred deletion now re-checks that the app is still gone and stands down when it is not. A removal that matched no row also no longer queues a deletion at all: it removed nothing, so it has no claim on the key, which may well hold another subject's live secret.The same trap was reachable by plugins and they had no way out of it.
removeConnectionandremoveIntegrationrun inside core's removal transaction — deliberately, so a plugin's own rows die atomically with the connection — which makes them exactly the wrong place to revoke a token at the provider's API, delete a remote object, or notify a third party. Nothing in the hooks' documentation said so, andPluginCtxexposedtransactionbut nothing to defer past it.PluginCtxgainsafterCommit. It runs the effect once the outermost transaction commits, discards it if that transaction rolls back, and runs it immediately when no transaction is active. The lifecycle hooks now document that they run inside core's transaction and that outside-world work belongs inafterCommit.Sequencing work after your own
transaction(...)call is not equivalent, and the documentation says so explicitly:transactionnests by pass-through, so inside an active transaction the inner call simply runs its effect and "afterwards" is still before any commit.Patch Changes
#1560
8c20c33Thanks @Adityakk9031! - Stale tool catalogs refresh together instead of one after another, and self-host can set the freshness windowA tools read rebuilds every connection whose catalog has gone stale. Those rebuilds each dial their own upstream, but ran strictly one after another, so a host with several stale remote catalogs paid the sum of every server's latency on the read that tripped the TTL. The upstream listings now run concurrently, bounded so a large stale set cannot open an unbounded number of listings from one read.
Only the listings overlap. Each rebuild's catalog write stays single-file, because a self-host database is one connection issuing raw
BEGIN/COMMITand a second transaction opened while one is live fails outright. A rebuild that fails now also logs a warning naming the connection and the reason, instead of disappearing: the read still succeeds on the stale-but-working catalog and the other connections still finish, but a permanently broken connection no longer re-fails silently on every read.Self-host also exposes the freshness window as
EXECUTOR_TOOLS_SYNC_TTL_MS. Leave it unset for the 15-minute default, or setoff(equivalentlynullorfalse, in any case) to disable time-based re-sync and leave stale-marking and config revision as the only refresh triggers. The value forwards to the SDK verbatim, so0keeps its SDK meaning: every catalog is expired on every read. A malformed, negative, or too-large-to-represent value is refused at boot rather than silently falling back to the default.#1569
d874455Thanks @GeiserX! - Abandoned authorization sessions no longer keep their PKCE verifier foreverAn OAuth authorization session stores its PKCE verifier so the callback can redeem the code.
completediscarded an expired session lazily, but an abandoned flow is never completed, so that check never ran for it and nothing else swept the table — the verifier sat there in plaintext indefinitely.Starting a new authorization now sweeps sessions that have already expired. Doing it on
startbounds the table by how often authorization is begun rather than by how often it is abandoned, and needs no scheduler in any host. A session whose completion cannot be retried is dropped rather than left behind.The sweep only ever reaches rows the caller can already see, so one member's authorization never touches another member's sessions. It is best-effort: a sweep that fails logs a warning and lets the authorization continue.
#1575
e5526f3Thanks @GeiserX! - GraphQL introspection no longer logs a credential carried in the endpoint URLqueryis a supported credential carrier, so a GraphQL endpoint can be reached with?token=<secret>. Introspection built its request from a URL string, andHttpClientRequest.setUrlkeeps a string verbatim asrequest.url. EveryHttpClientErrorrenders${method} ${request.url}into itsmessagegetter, and introspection logs the raw failure cause — so on any transport failure or non-JSON response, the connection's secret was written to the process log.The request is now built from a URL object, which moves the query into
request.urlParamsand clears it fromrequest.url. The secret is therefore absent from the error message, and from anything else that renders the request URL. The credential still reaches the upstream: the client recombines url and urlParams when it executes the request. The endpoint's own query string is handled the same way, not just the separately-supplied query parameters, since a configured endpoint can carry a credential too.The query string is now normalized on the wire. Recombination appends each pair through
URLSearchParams, so the query is re-serialized in form-urlencoded form instead of passed through byte-for-byte:%20is sent as+~and!'()are percent-encoded?flagis sent asflag=Key order, repeated keys, and already-encoded reserved characters are unchanged, and every parameter still decodes to the same value. This is not avoidable while the fix holds: raw query bytes only survive inside
request.url, which is the one field every error message renders, so byte-transparency and keeping the credential out of the log cannot both hold. An upstream that signs its raw query string is the case to watch. The exact resulting URLs are pinned by test.Two endpoints are now rejected up front with an
invalid-endpointfailure rather than dialed:https://user:pass@host/…), whichURLkeeps in the origin, so it would stay inrequest.urland leak into error messages exactly the way a query-carried secret used toNeither rejection echoes any part of the endpoint. A health check on such an integration now reports the invalid configuration and points the operator at the endpoint URL, instead of blaming the credential that was never sent.
#1596
b77ee69Thanks @GeiserX! - Credentials are kept out of the health-check result that gets persistedA health check stores a sample of the probed operation's response body, plus the extracted identity, in
connection.last_health— so whatever those carry is written to the database. The operation is user-chosen from the plugin's catalog, which means it can just as easily be a key-listing endpoint as a/me, and those return secrets that no scrub of the connection's own credential value can recognise, because they are different secrets entirely.Two passes now cover both kinds of secret:
token,api_key,secret,authorization,session, …) have their value replaced with[redacted]. The row itself is kept, so the live preview still shows the response shape and the identity picker still works. Keys that merely contain a matching substring, such asauthor, are left alone. camelCase spellings are recognised too:accessToken,refreshToken,clientSecret,privateKeyandsessionIdhave no separator before the credential word, so a matcher that only looks for one reads them as innocent.The key check reads a dotted path two ways. It uses the nearest NAMED segment, because array elements are named by index:
{"tokens": ["sk-live-…"]}produces the pathtokens.0, and testing the literal"0"matches nothing. It also uses an enclosing array container, because a key listing returns{"api_keys": [{"value": "sk-live-…"}]}, whose path isapi_keys.0.value— the nearest named segment there is the innocentvalue, and only the array's own key says what the collection holds. A collection whose key names nothing, such asnames.0, is still shown in full.The extracted
identitygoes through both passes as well. It is read straight off the raw body, so it previously bypassed them even though it is persisted the same way, andidentityFieldis user-chosen from whatever the picker listed.#1607
75c917fThanks @timkley! - Fix: allow MCP integrations to declare OAuth scopes when resource metadata omits themMCP OAuth methods can now carry an optional non-empty scope list. Declared scopes
take precedence over protected-resource scope discovery, so servers with fixed
scopes can connect even when their dynamically registered OAuth client has no
resource identifier. Existing integrations without declared scopes keep
discovering them from the server at connect time.
#1577
4879d47Thanks @GeiserX! - Idle MCP connections age out on the pool's next acquire, even when their identity is never dialled againThe pool's five-minute idle window was only consulted against the entry being requested, so an identity that was never asked for a second time was never examined a second time. Its session stayed open and authenticated for as long as the pool lived, holding the bearer token or API key it was dialled with. The advertised bound applied only to connections that happened to be reused.
acquirenow sweeps every entry past the window, closing each one, rather than just the entry matching the key. This stays lazy in the sense the pool intends — activity drives it, there is no timer and no background fiber — and the map holds at most one entry per identity, so the scan is trivial.Because the sweep is paid for by whichever invocation acquires next, it cannot be allowed to stall that caller. The expired entries leave the pool synchronously, before any close is awaited, and the closes then run concurrently with each one bounded by a two-second timeout — so a server that accepts a close and goes quiet is abandoned rather than waited on, and cannot hold up an unrelated request or the connections queued behind it.
Reuse is unchanged: an entry still inside the window is left alone, and a second call for the same identity still gets the parked session rather than a fresh dial.
#1377
98615b4Thanks @RhysSullivan! - A credential-store outage no longer costs an OAuth connection its grantRefreshing an OAuth token spends the stored refresh token: the authorization server rotates it, so the copy we sent stops working the moment the grant succeeds and the rotated one is the only thing that can mint again. Persisting the rotated token first bounds what a partial write can lose, but it cannot help when the store is refusing writes outright — the grant has already run, there is nowhere to put the successor, and every later refresh replays a token the server has revoked. The connection then reports
invalid_grantand demands a re-auth over what was only a storage blip.The refresh is now gated on a store that is proven writable. Before the grant runs, it writes a fixed value to an item of its own that holds no credential and sits in the same partition as the connection's tokens. A store that cannot take that write fails the resolve while the stored refresh token is still valid, so the connection recovers on its own once the store does.
The probe deliberately does not test the store by rewriting the refresh token with the value it just read. That is a read-then-write with no compare-and-set, and two instances refreshing one connection would lose the newer token to it: one reads the stored token, the other spends that same token and stores its rotated replacement, and the first then writes the spent one back over the replacement. The connection would die exactly the way the gate is meant to prevent.
The probe also removes a write rather than adding one in the common case. Authorization servers that do not rotate hand back the same refresh token, and that value is no longer re-persisted when it has not changed — a rotated token never matches, so the write that matters still happens.
#1567
6225d5eThanks @GeiserX! - Keep token material out of OAuth token-endpoint error messagesA token-endpoint failure renders a preview of the upstream body into its
message, and that message is persisted onto connection health, returned to the
caller, and carried into telemetry. On a malformed HTTP 200 the body being
previewed is a successful token response, so an access token and a refresh
token could be rendered into it.
The preview is now built from an allowlist of fields that are safe to show
(
error,errors,error_description,error_uri, pluscode,message,and
detailnested inside them) instead of a denylist of fields to hide. Afield nobody anticipated is omitted by default rather than printed by default.
Keys stay visible and only non-allowlisted string values are replaced, so an
operator can still read the shape of what the server sent.
codeis readableonly when nested, because at the top level of a token response it is the RFC
6749 authorization code.
Form-encoded bodies take the same allowlist, the walk over a body is
depth-bounded, and the failure summary records the token endpoint's hostname
rather than its full URL, which can carry identifiers in its path.
On that same malformed-200 path the failure no longer keeps the underlying
rejection as its
cause. That rejection carries the parsed token response, sokeeping it put the raw tokens back into anything that renders the whole failure
rather than only its message. Everything the path needs from the body — the
status, the error code, the redacted preview — is read before the failure is
built. A transport failure still keeps its cause, which is what tells a DNS miss
apart from a refused connection.
No public API changes. The dead-grant classification added for HTTP 200 refresh
refusals is unaffected: it reads the HTTP status, not the rendered preview.
#1772
597ce90Thanks @baggiiiie! - Persist the Connect-an-agent card's transport, artifact, integration-search, and approval preferences in the browser so its generated MCP install command remains stable across page reloads.#1529
0004ea3Thanks @jadch! - Keep Last-Event-ID recovery scoped to its originating MCP stream.Updated dependencies [
1908dd6]:@executor-js/cloud@1.4.64
Patch Changes
#1806
93817edThanks @RhysSullivan! - Team pricing is per member with unlimited executionsThe Team plan moves from $150 per organization with a 250,000-execution
allowance to $15 per member per month with unlimited executions. The
membersfeature is unarchived inautumn.config.tsand billed in arrearson the seat count the app reports; Free keeps its 3-member, 100,000-execution
shape and Enterprise stays custom with seat usage tracked for visibility.
Seat counts reconcile from a full WorkOS recount (active members only —
pending invites hold a seat for the plan gate but are not billed) after
member removal, invitation acceptance, organization creation, and on every
login callback, which also picks up joins the app never sees a mutation for
(SSO JIT provisioning, join by domain, dashboard edits). Plans that predate
seat pricing have no members balance and are skipped, so existing
subscriptions keep billing exactly as before on their current plan version.
The plans page, billing page, and marketing pricing cards now show the
per-member price.
Updated dependencies [
8324e1e,85b1955]:@executor-js/host-selfhost@0.0.45
Patch Changes
8324e1e,85b1955]:@executor-js/local@1.7.0
Patch Changes
#1458
1908dd6Thanks @tylergibbs1! - An unsupported method probed beforeinitializeno longer kills the MCP connectionOnly
initializecan open a session, so the streamable-HTTP transport answered every other pre-session method with HTTP 400 +-32000 Server not initialized. A 400 is a transport-level failure, so clients dropped the connection instead of treating it as one request failing — a client that opens with an optional probe (MCP 2026-07-28 clients lead withserver/discover) was disconnected before it could fall back toinitialize. Overexecutor mcp, which bridges this endpoint to stdio, that closed the client's pipe outright.Pre-session dispatch now answers any method other than
initializewith-32601 Method not foundon a normal 200, which is a per-request error, so the connection survives and the handshake proceeds. This replaces only that one answer: a POST with a badAcceptorContent-Typestill gets the transport's 406 or 415, and a message that is not a valid JSON-RPC request still gets its parse error.Updated dependencies [
8324e1e,85b1955]:@executor-js/e2e@0.0.43
Patch Changes
8324e1e,85b1955]:@executor-js/example-all-plugins@0.0.64
Patch Changes
8324e1e,85b1955]:@executor-js/example-docs-sdk-quickstart@0.0.49
Patch Changes
85b1955]:@executor-js/analytics@0.1.10
Patch Changes
@executor-js/api@1.4.66
Patch Changes
@executor-js/cloudflare@0.0.45
Patch Changes
@executor-js/mcp-apps-shell@1.4.14
Patch Changes
@executor-js/runtime-workerd-subprocess@0.0.18
Patch Changes
@executor-js/plugin-encrypted-secrets@0.0.45
Patch Changes
@executor-js/plugin-provider-service-split@0.0.17
Patch Changes
85b1955]:@executor-js/react@1.4.66
Patch Changes
@executor-js/desktop@1.7.0