Report honest removed flag from oauth.clients.remove

[RhysSullivan]

Follow-up to #1600, found by using it: while cleaning up 8 unused OAuth clients, one of the removals reported { removed: true } and deleted nothing. Only the arithmetic gave it away — 20 clients minus 8 removals left 13, not 12.

oauth.removeClient is idempotent by design at the storage layer (deleteMany on a missing row is a no-op, which is correct for a delete), but the tool mapped that silence to unconditional success. So a typo'd slug, an already-deleted client, and the wrong owner were all indistinguishable from a real deletion. I confirmed the extreme case against production: removing definitely-not-a-real-client also returned { removed: true }.

It bites hardest because clients are keyed by both owner and slug, so the same slug can exist separately under org and user. A sweep over a list of slugs with one hardcoded owner deletes only the matching half and reports every call as success — which is exactly what happened: a microsoft-graph OAuth app stayed registered under org after everything it authorized had been deleted.

The tool now checks the caller-visible client set first and returns removed: false when nothing matched that (owner, slug) pair. The service-level removeClient is unchanged and stays idempotent — the honesty belongs at the agent boundary, matching integrations.remove from #1600.

Verification

• New test in oauth-remove-client.test.ts covers the exact shape that hid the bug: the same slug registered under both owners, removed one owner at a time, plus a never-existed slug and a repeat removal.
• Confirmed the test is not vacuous — reverting the fix fails it with expected { removed: true } to deeply equal { removed: false }.
• format:check, lint, repo-wide typecheck clean; packages/core/sdk 599/599.

Not in this PR

oauth.clients.list returns owner and slug as separate fields with no single unambiguous identifier, which is what let two microsoft-graph rows read as one entry when scanning the output. An owner-qualified address field would prevent that class of misread, but it changes an output schema, so it seemed worth deciding separately.

[github-actions]

Cloudflare preview

Torn down — the PR is closed.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	executor-marketing	5dec04e	Commit Preview URL Branch Preview URL	Aug 16 2026, 12:31 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	executor-cloud	5dec04e	Aug 16 2026, 12:32 PM

[pkg-pr-new]

Open in StackBlitz

@executor-js/cli

npm i https://pkg.pr.new/@executor-js/cli@1603

@executor-js/config

npm i https://pkg.pr.new/@executor-js/config@1603

@executor-js/execution

npm i https://pkg.pr.new/@executor-js/execution@1603

@executor-js/sdk

npm i https://pkg.pr.new/@executor-js/sdk@1603

@executor-js/codemode-core

npm i https://pkg.pr.new/@executor-js/codemode-core@1603

@executor-js/runtime-quickjs

npm i https://pkg.pr.new/@executor-js/runtime-quickjs@1603

@executor-js/plugin-file-secrets

npm i https://pkg.pr.new/@executor-js/plugin-file-secrets@1603

@executor-js/plugin-graphql

npm i https://pkg.pr.new/@executor-js/plugin-graphql@1603

@executor-js/plugin-keychain

npm i https://pkg.pr.new/@executor-js/plugin-keychain@1603

@executor-js/plugin-mcp

npm i https://pkg.pr.new/@executor-js/plugin-mcp@1603

@executor-js/plugin-onepassword

npm i https://pkg.pr.new/@executor-js/plugin-onepassword@1603

@executor-js/plugin-openapi

npm i https://pkg.pr.new/@executor-js/plugin-openapi@1603

executor

npm i https://pkg.pr.new/executor@1603

commit: 5dec04e