[Bug]: Existing-project plugin selection is dropped and restricted pipeline grants are ignored

[itlackey]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

Two related host defects prevent pipeline plugins from reliably reaching existing-project runs:

1. POST /api/plugins/:id/apply correctly returns a pure snapshot with snapshotId: "", but the web send path forwards only that empty ID. /api/runs receives neither pluginId nor pluginInputs, so the selected plugin is omitted or an older project pin is reused.
2. A restricted plugin with od.pipeline.stages requires pipeline:*, but the trust endpoint rejects that exact capability. If the grant is otherwise persisted, applyPlugin() recomputes defaults instead of using capabilitiesGranted, so the grant is ignored and revoked trusted capabilities can reappear.

Steps to reproduce

1. Install a plugin with od.pipeline.stages and attach it from an existing project's composer.
2. Send a message and inspect POST /api/runs; the request has no plugin identity or inputs because pure apply returned an empty snapshot ID.
3. Install the same plugin from a URL/GitHub source so it is restricted.
4. Run od plugin trust <id> --capabilities pipeline:*; the daemon returns invalid-capability.
5. Persist the grant directly and apply again; the snapshot still uses recomputed trust defaults rather than the stored grants.

Expected behavior

When pure apply has no snapshot ID, the existing-project run should send pluginId and pluginInputs so the daemon can persist and pin the snapshot. pipeline:* should be a valid persistent grant, and apply should honor stored grants while retaining the prompt:inject floor.

Open Design version

0.16.1, reproduced on main at f52fda29a

Platform

Linux

Logs (optional)

POST /api/plugins/<id>/trust -> 400 invalid-capability: pipeline:*
POST /api/runs -> 409 capabilities-required after the grant is stored

Screenshots (optional)

Not applicable.

Additional context

Reproduced with a real custom publishing plugin and isolated daemon data. Relevant paths are ProjectView.tsx -> providers/daemon.ts -> /api/runs, plus plugins/trust.ts and plugins/apply.ts. Focused regression tests and an imported-project fake-agent run confirm the expected behavior.

Note: I did use opencode and GPT 5.6 Sol to do this investigation and a PR with fixes for the issues I ran into testing a custom plugin.

[lefarcen]

Hi @itlackey — thanks for the tight repro and for tracing this through ProjectView.tsx / providers/daemon.ts plus the trust/apply paths.

I dug through the current code and this does look like a real two-part regression:

• the existing-project send path currently forwards only appliedPluginSnapshotId, so when pure apply returns snapshotId: "" there is no fallback pluginId / pluginInputs payload for /api/runs;
• validateCapabilityList() currently rejects pipeline:*, and applyPlugin() rebuilds capabilitiesGranted from the trust tier instead of the stored grant set, which matches the ignored persisted-grant behavior you described.

So this is in confirmed-bug territory rather than "needs more info". We’ll track it from those paths. If you already have a branch with the focused regression tests you mentioned, feel free to link it here — that would tighten the fix path even more.

[itlackey]

Hey @lefarcen I have pushed a branch to my fork with the tests and patches. Here are the commits.

Happy to submit this as a PR if it looks good to you.

[lefarcen]

Hey @itlackey — yes, please open it as a PR. The compare you linked lines up with the two issue paths here: forwarding pure plugin applies into /api/runs, and honoring persisted capability grants for restricted plugins. The added daemon/web regression coverage is the right direction too.

Once the PR is up, we can review it there against the current head.

[lefarcen]

PR #6187 is now up for this. It carries the same two concrete fixes described here: forwarding pure plugin applies into /api/runs when the snapshot is still unpinned, and preserving persisted capability grants/revocations instead of recomputing defaults on apply.

We'll track the implementation in #6187, but this issue stays open until that PR lands and the regression is confirmed there.