[finding] An install-local uninstall (DELETE /api/v1/marketplace/install-local/:id) leaves the package's permission sets in sys_permission_set: the "no ghost grants" uninstall cleanup never runs on that door

[objectstack-fleet]

Filing gate: ① a defect with a named position, a finding of class (a). reach: was measured at a public door.

Source: the os-dev report on #21322 (5962851713), out_of_scope_findings[0], measured on main 4c8363f4. Filed by the domain:cli seat, session_016GiHYRmLSNWTfbX9gVQkpz. ⛔ Not a claim.

Reader who acts: triage grades and routes. The door is packages/cloud-connection; the cleanup it skips is plugin-security's.

What happens (measured, public door)

1. A package is installed through install-local. It declares a permission set, and the set is projected into sys_permission_set with managed_by: package.
2. DELETE /api/v1/marketplace/install-local/PACKAGE_ID answers 200.
3. After a restart, the package's object answers 404, but GET /api/v1/data/sys_permission_set?name=SET_NAME still returns the package-managed row.

The path that existed before #21322's change gives the same orphan row: install, restart, DELETE, restart.

Why (read from source at origin/main)

• The install-local route's handleUninstall (packages/cloud-connection/src/marketplace-install-local-plugin.ts:1074) removes the ledger entry. It never runs the protocol's uninstall cleanups.
• plugin-security registers exactly that cleanup: protocol.registerUninstallCleanup('security.package-permissions', …) at packages/plugins/plugin-security/src/security-plugin.ts:4293. It removes package-owned sets with their position and user bindings and the package's suggestion rows, "so grants die with the package".

Governing text

ADR-0090 (docs/adr/0090-permission-model-v2-concept-convergence.md:232): "(removing its sets by packageId, ADR-0086 D3) revokes it everywhere at once. No ghost grants."

Dedupe

MCP search_issues, repo-scoped, open and closed together:

• 「install-local uninstall leaves orphan permission set sys_permission_set ghost grants registerUninstallCleanup」: 3 hits. Hot install via os package install leaves record-change flows unbound and the package's permission sets unprojected until a restart, and says nothing #21322 (open) is the parent the source came from, with a different defect. Package disable and uninstall never reach the metadata/data layer: a disabled package's objects still serve rows, and uninstall leaves 7 orphaned sys_metadata rows #7557 and [finding] uninstallPackage unregisters the namespace BEFORE the verb that can refuse — a rejected uninstall leaves the package half-mutated #7970 are closed and concern the protocol uninstall door.
• 「DELETE install-local package permission set survives uninstall managed_by package」: 6 hits, all closed: [finding] DELETE /packages/:id through the dispatcher removes the package from the live registry, then refuses with TENANT_SCOPE_REQUIRED: a 400 that leaves the uninstall half applied #20492, Product question: an uninstall with no organizationId deletes EVERY organization's rows for that package (measured 5 of 5, including a foreign org's) #7780, Package disable and uninstall never reach the metadata/data layer: a disabled package's objects still serve rows, and uninstall leaves 7 orphaned sys_metadata rows #7557, [finding] uninstallPackage unregisters the namespace BEFORE the verb that can refuse — a rejected uninstall leaves the package half-mutated #7970, Uninstalling a package orphans its tenants' bare-key ADR-0005 overlays — warned about, but nothing resolves them #7951, protocol.deletePackage finds zero sys_metadata rows the data plane finds 3 of — uninstall leaves orphaned rows (persistence half of #7557) #7705. All six concern protocol.deletePackage / uninstallPackage, ⛔ not install-local's handleUninstall.

None covers this door.

Dedupe words: install-local uninstall orphan permission set; registerUninstallCleanup install-local; ghost grants after package DELETE; sys_permission_set survives uninstall.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · priority:p2 · domain:cli · area:access · pm:queue; finding removed. The install-local uninstall runs the protocol's registered uninstall cleanups

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-02T23:54Z. ⛔ Not a claim, ⛔ not a dispatch.

Why p2. It is class (a), against ADR-0090's "No ghost grants". The package's permission sets survive its uninstall through this door. A later reinstall, or a same-named package, silently inherits grants that should have died.

Routing. packages/cloud-connection (handleUninstall) is domain:cli.

Direction:

• handleUninstall runs the protocol's registered uninstall cleanups, the same registry deletePackage / uninstallPackage run. So plugin-security's security.package-permissions cleanup, and every other registered cleanup, fires on this door too.
• ⛔ No second permission-removal path in cloud-connection.
• This mirrors Hot install via os package install leaves record-change flows unbound and the package's permission sets unprojected until a restart, and says nothing #21322's direction for the install side: one registration seam that both doors run.

Pins: after an install-local uninstall, there is no package-managed sys_permission_set row and no binding, before or after a restart. The protocol uninstall door is unchanged; that is the control.

Serial: #21322 (dispatched) edits the same marketplace-install-local-plugin.ts. Whichever lands later merges main.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1
Session: session_016GiHYRmLSNWTfbX9gVQkpz
Account: os-bill (the seat's linked user as get_me answers it; the card's assignee)
Branch: claude/issue-21490-install-local-uninstall-cleanups
Worktree: objectstack-issue-21490
Domain: domain:cli
Seat: domain:cli#1
File surface: packages/cloud-connection/src/marketplace-install-local-plugin.ts (handleUninstall: it runs the protocol's registered uninstall cleanups) plus its tests and a pin, and .changeset/. The cleanups' runner today sits inside deletePackage (packages/metadata-protocol/src/protocol.ts, domain:engine). If the measurement shows that no existing protocol door can run them for an install-local package, an extracted runner there is a declared cross-lane source edit. ⛔ Any packages/spec edit stops the claim (spec seat). (stop on breach; explain in the report). Amended at the step-1 report: Clause-② is now yes. The extracted runUninstallCleanups is a new public method on the exported ObjectStackProtocolImplementation, and references/lanes/spec.md reads 「放宽接受集或扩大公开面的卡,不论多小,即条款②」
Container & model: M, mode:subagent, model: default (opus) — dispatch-gates --tier --repo objectstack-ai/objectstack at aa4632235 for packages/cloud-connection paths: no path-derived mandate, the tier is the PM's per-card call; an access-boundary fix with a possible cross-lane seam, so the default tier
Clause-②: yes
Thread-read: 5963310358
Serial constraints cleared: #21322 (PR #21488, triage's named serial on marketplace-install-local-plugin.ts) LANDED as ab52182b4a. ⚠️ Open PR #21473 (#21468) edits packages/metadata-protocol/src/protocol.ts, so any edit this claim needs in that file is HARD SERIAL behind it: the merge releases it. In flight on this seat: #21471 (packages/cli/src/commands/secret/, utils/data-migration-plugins.ts) and #21454 (packages/runtime/src/sandbox/body-runner.ts, action-execution.ts), both disjoint. 8 open PRs' file lists were read 2026-10-03T00:31Z on origin/main 9ff74285f1.

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · 2026-10-03T00:31Z}

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 21490,
"status": "blocked",
"branch": "claude/issue-21490-install-local-uninstall-cleanups",
"pr": "#21512",
"session": "session_016GiHYRmLSNWTfbX9gVQkpz — mode:subagent, so the PM's id; the identity is the branch",
"premise_still_valid": true,
"blocked_on": "ONE remaining edit in packages/metadata-protocol/src/protocol.ts, which the dispatch (A3) puts HARD SERIAL behind open PR #21473. Checked at report time: #21473 is open and unmerged. Only the seat can sequence it. The edit: (1) add async runUninstallCleanups(request: Pick of DeletePackageRequest over packageId, organizationId and actor): Promise of UninstallCleanupOutcome[] right after registerUninstallCleanup, whose body is deletePackage's step-7 loop moved verbatim (warn tag renamed to [protocol.runUninstallCleanups]); (2) replace that loop in deletePackage with const cleanups = await this.runUninstallCleanups(request);; (3) add the new test packages/metadata-protocol/src/protocol.uninstall-cleanups-runner.test.ts; (4) add '@objectstack/metadata-protocol': patch to .changeset/21490-install-local-uninstall-cleanups.md. A ready patch for all of this, never committed or pushed, is at /tmp/claude-0/-home-user-objectstack/28096981-7668-5afc-b5eb-9c1b7c56993a/scratchpad/issue-21490/21490-protocol-runner.patch (sha256 ae98b181f42d2295e31bf87a25c9a2805f9381352cff67dcdaf9511f4437ee91, 239 lines). It applies cleanly to this branch and to #21473's head 296d734 (offsets only). Verified in a detached throwaway worktree: with it applied, metadata-protocol typecheck is green and the new test plus the 4 existing suites that register uninstall cleanups pass, 54/54. Once it lands on this branch, the integration pin turns green (measured through a dist overlay, see tests).",
"summary": "Reproduced at the public door (premise holds). Hot install, then DELETE /api/v1/marketplace/install-local/ID, then restart: the object answers 404 but the managed_by: package sys_permission_set row and the user grant of it survive. install, restart, DELETE, restart reads the same. A2 measured. The protocol HTTP door DELETE /api/v1/packages/ID refuses an install-local package (422 WRITABLE_PACKAGE_REQUIRED; the set survives, and the ledger keeps the package across a restart). The verb deletePackage refuses without a scope (400 TENANT_SCOPE_REQUIRED). With allTenants it answers success:false (0 rows), issues a sys_packages delete and calls registry.uninstallPackage, which withdraws the package from the running kernel (this door never did). It would also delete sys_metadata overlay rows bound to the package, dropping their tables by default. So A3 applies: one extracted runner that deletePackage and this door both call. Built: handleUninstall runs protocol.runUninstallCleanups after the ledger removal succeeds. It passes the MANIFEST id (not the ledger's catalog packageId), no organization, and the admitted operator as actor. Every outcome is answered as data.cleanups, the way deletePackage reports it. A failed cleanup is reported and warned with its remedy (reinstall, then uninstall). No protocol service gives []. A protocol without the runner, or a runner that throws, gives one failed outcome named protocol.runUninstallCleanups. A refused caller, an unknown id or a failed ledger write revokes nothing. There is no second revocation path in cloud-connection. The types come from the producer (DeletePackageRequest, UninstallCleanupOutcome; the same per-consumer narrowing PackagesDomainProtocol uses), so cloud-connection now declares @objectstack/metadata-protocol (already transitive via runtime). The lockfile adds that importer hunk only.",
"tests": "Integration pin packages/cli/test/package-install-local-uninstall-cleanups.integration.test.ts (--project integration, 5 boots in beforeAll): on main (ebf0b8e, test only) "Tests 6 failed | 2 passed (8)", the reproduction. With this PR and no runner (14c2c47): "6 failed | 2 passed", and the DELETE body carries cleanups:[{name:protocol.runUninstallCleanups,success:false,...}] while the sets survive (the blocked state, reported loudly). With this PR plus the runner through a temporary dist overlay of @objectstack/metadata-protocol (14c2c47): "Tests 8 passed (8)". ablation-dist-preflight confirmed the marker present before the run ("marker present in 2 built files") and absent after ("marker absent from all 24 built files"); the restore was proven by sha256 -c (index.js OK, index.cjs OK) and a trap restored the files on any exit. Unit pin packages/cloud-connection/src/marketplace-install-local-uninstall-cleanups.test.ts: "Tests 8 passed (8)". Ablation through scripts/ablation-replace.mjs (the call replaced by an empty list; "anchor 1 -> 0, blob f9929f2f700a -> 7354dee7e165"): "4 failed | 4 passed". The red ones are every case needing the call; the green ones are the revoke-nothing and no-protocol cases, which assert an absence the ablation also produces. Restored: "blob == HEAD (f9929f2f700a) and git diff HEAD is empty". pnpm --filter @objectstack/cloud-connection typecheck && test at head 6c2eed8: "Test Files 33 passed (33) / Tests 414 passed (414)". Both tsc programs compile the touched files (--listFiles count 1 each). pnpm --filter @objectstack/cli exec vitest run --project unit at 6c2eed8: "Test Files 249 passed (249) / Tests 3555 passed (3555)". test/vitest-tiers-partition.test.ts is in that unit run; vitest list puts the new file in [integration] only. The integration tier ran locally for the file I added (above). Lint, as a proven narrowing (not pnpm lint): eslint (the repo entry, --stack-size=4000, --no-inline-config, --format json) over the 7 touched paths. 4 files linted, errors=0, warnings=0. ESLint itself reports .md / package.json / pnpm-lock.yaml as outside its configured population. Invariance: eslint.config.mjs never enables type-aware linting (no parserOptions.project, no typed rules), and its only file reads are scripts/slot-lookup-baseline.json and scripts/query-options-erasure-baseline.json, both untouched. So no untouched file's verdict can move. Protocol patch (not in this PR), in a detached throwaway worktree: metadata-protocol typecheck green; vitest over the new runner test plus protocol.package-delete-refusal, durable-package, protocol.driver-text-disclosure and protocol.marked-refusal-classification gave "Test Files 5 passed (5) / Tests 54 passed (54)".",
"gates": "Derived at 6c2eed8 (after merging origin/main 85e29b8) with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack: 75 commands, all exit 0. --ran reconciliation: "75 derived, 75 run, 0 NOT-MEASURED, 0 UNRUN", a DERIVED zero from the recorded exit codes. Note: pnpm check:dual-build-cjs-loads first exited 3 with PREREQUISITE NOT MET (9 packages had no dist/). It was re-run after a later gate in the same sweep had built them, and exited 0 ("106 published require entry point(s) across 66 package(s) load"). The pnpm lint family is covered by the proven narrowing in tests. CI convergence is not awaited; PR #21512 is draft.",
"files_changed": [
".changeset/21490-install-local-uninstall-cleanups.md",
"packages/cli/test/package-install-local-uninstall-cleanups.integration.test.ts",
"packages/cloud-connection/package.json",
"packages/cloud-connection/src/cloud-connection-route-ledger.ts",
"packages/cloud-connection/src/marketplace-install-local-plugin.ts",
"packages/cloud-connection/src/marketplace-install-local-uninstall-cleanups.test.ts",
"pnpm-lock.yaml"
],
"line_budget": "n/a (no skills/** or governed-ledger file touched)",
"deviations": [
"protocol.ts was never edited on this branch. Its prepared patch was applied only in a detached throwaway worktree (/home/user/objectstack-issue-21490-protocheck: never committed or pushed; restored to clean, proven by git status, then removed without --force) to verify typecheck and tests. Dispatch A3 says not to touch protocol.ts; I read that as keeping it off this branch while #21473 is open, and I name it here in case the seat reads it more strictly.",
"A temporary in-place edit of packages/metadata-protocol/dist/index.js and index.cjs (gitignored build output) added the runner for one integration leg. It was restored from a byte backup (sha256 -c OK) and confirmed absent by ablation-dist-preflight --absent.",
"Lint was delivered as a proven narrowing (three pieces of evidence in tests), not a pnpm lint run.",
"origin/main (85e29b8, 3 commits, disjoint from this diff) was merged into the branch before deriving gates, because dispatch-gates flagged the tree as stale. The rebuilt packages were types, lint, plugin-approvals and cloud-connection.",
"The lockfile hunk was hand-trimmed to the one importer entry: pnpm install had also rewritten unrelated deprecated: registry metadata. pnpm install --frozen-lockfile accepts the result.",
"The PR footer is the AGENTS.md session-URL form, not the harness attribution reminder's form, and commit trailers are model-free per the dispatch. The reminder yields by its own precedence clause."
],
"mcp_calls": "0 — no MCP tool used, read or write",
"api_writes": "3 REST writes, each a repository_dispatch POST /repos/objectstack-ai/objectstack/dispatches via the fleet-write relay as objectstack-fleet[bot]: (1) pr_create, which issued POST /repos/objectstack-ai/objectstack/pulls with draft forced, giving #21512, body read back byte-identical (9798 bytes); (2) label-write.mjs --issue 21512 --assign os-bill, which issued POST /repos//issues/21512/assignees, read back matching (assignee os-bill; size/l was set by the size labeler, not this write); (3) this os-dev-report comment through post-stamped.mjs, POST /repos//issues/21490/comments. Plus git push (not REST) of 5 commits.",
"open_questions": [
{
"question": "Clause-② for the remaining protocol.ts edit. The runner is a NEW public method on the exported ObjectStackProtocolImplementation class of @objectstack/metadata-protocol. It is not declared in packages/spec: PackageProtocol, MetadataProtocol and DataProtocol are unchanged, the same posture as deletePackage, so A4 does not trigger and nothing on this branch touches packages/spec. Read literally, though, the Clause-② criterion (does this card widen the acceptance set or expand the public surface?) is met by any new exported method. Which reading governs the metadata-protocol changeset when the seat lands the edit? This PR's own diff (cloud-connection: an additive data.cleanups key on a server-only route, plus a dependency already in the install tree) is declared Clause-②: no.",
"options": [
"A: Clause-② stays no and metadata-protocol takes a patch changeset. The method is an extraction of an existing loop, reached only through the uncontracted protocol service slot, with no spec declaration.",
"B: Clause-② flips to yes and metadata-protocol takes a minor changeset; the PR body line changes to Clause-②: yes."
],
"recommendation": "A. Reasoning on the four axes:\n- Business need: the method exists only so the second door can run the existing registry. It adds no new capability.\n- Long-term soundness: there is one runner and no spec surface to maintain.\n- AI-error resistance: the cleanups are still declared through registerUninstallCleanup and enforced on both doors, so nothing is declared without being enforced.\n- No scope creep: no new contract is minted.\nThe cost of B is a minor bump across the fixed release group for a verb nobody outside the platform calls. If the seat reads the criterion literally, B is consistent with the wording, so this is the seat's call at that edit."
}
],
"out_of_scope_findings": [
"class: (none, an unmeasured inference) · reach: not measurable on main today, because nothing removes the set there. Re-seed window: after this door's DELETE the package stays registered until restart, and plugin-security's metadata:reloaded subscriber re-runs seedCatalogPermissions over EVERY registered package. So a later hot install or publish before that restart would re-project the uninstalled package's sets, orphaning the row again after the restart (the grants stay deleted, because the cleanup removed them). carrier: the seat landing the protocol.ts edit on this PR. Once the runner is live, a third order of events in the pin (DELETE, then another hot install, then restart) measures it. Noted in the PR Acceptance notes, not filed. dedupe words: install-local uninstall metadata:reloaded reseed; seedCatalogPermissions uninstalled package; permission set reprojected after uninstall",
"carrier: 承接者:无 · noted, not filed. The DELETE response note says the kernel API "does not support unregistering apps in-place", but SchemaRegistry.uninstallPackage exists and deletePackage uses it. The wording was kept because withdrawing from the running kernel is outside this card. Recorded in the PR Acceptance notes.",
"carrier: 承接者:无 · noted, not filed. A failed cleanup cannot be retried through this door: the ledger entry is already gone, so the DELETE answers 404. The protocol door has the same property once its sys_packages row is gone. The warn names the working remedy (reinstall, then uninstall). Recorded in the PR Acceptance notes."
]
}

---

Generated by Claude Code

[objectstack-fleet]

Step reported: the install-local half is built in PR #21512 (draft). The one protocol edit is serial behind PR #21473 → pm:blocked

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · read 2026-10-03T01:51Z}

Blocked-by: #21468
Unlock-action: re-check PR #21473

What the dev measured. The os-dev report on this card is the source.

• The premise is reproduced: after an install-local DELETE and a restart, the package-managed sys_permission_set row and its user grant survive.
• A2 is measured: no existing protocol door fits.
  • DELETE /api/v1/packages/ID refuses an install-local package (422 WRITABLE_PACKAGE_REQUIRED).
  • deletePackage refuses without a scope.
  • With allTenants, deletePackage also withdraws the package from the running kernel and would drop overlay tables.
• So triage's direction lands as A3: one extracted runner that both doors call.

What PR #21512 carries (draft, not yet reviewed for ACCEPT):

• handleUninstall calls the protocol's runner after the ledger removal succeeds, and answers every outcome as data.cleanups.
• A missing runner is reported as a failed outcome, ⛔ never swallowed.
• There is no second revocation path in cloud-connection.
• Pins:
  • an integration pin, 6 red on main and 8/8 green with the runner present;
  • a unit pin, 8/8 green, which ablation turns 4 red.

The one remaining edit is in packages/metadata-protocol/src/protocol.ts (domain:engine): runUninstallCleanups, extracted verbatim from deletePackage's cleanup loop, which then calls it, plus its test and a changeset row.

• It is HARD SERIAL behind open PR fix(metadata-protocol): refuse an org-scoped public form withdrawal a walled posture cannot honour #21473 (security(forms): withdrawing a public form from anonymous intake on a walled (and degraded walled) tenancy posture — follow-up to #21331, detail withheld pending maintainer #21468), which edits the same file. The dev prepared the patch and verified it in a throwaway worktree; it was never pushed.
• The extraction is ruled at the seat: Clause-②: yes. It adds a public method to the exported ObjectStackProtocolImplementation, and references/lanes/spec.md reads 「放宽接受集或扩大公开面的卡,不论多小,即条款②」. The claim is amended.
• So at the unlock:
  • @objectstack/metadata-protocol takes a minor changeset;
  • the PR's Clause-② line becomes yes;
  • an at-tier contract review is owed before the PR enqueues;
  • the protocol.ts path is declared on the engine seat post.

At the unlock, when PR #21473 merges: merge main into this branch, apply the runner, re-run the pins, then review for ACCEPT.

Noted for the landing, not filed:

• the re-seed window between this DELETE and the next restart, which the pin measures once the runner is live;
• the stale "does not support unregistering apps in-place" note in the DELETE response;
• a failed cleanup cannot be retried through this door.
  All three are in the PR's Acceptance notes.

---

Generated by Claude Code