Symposium & Dial9: A disabled plugin installs anyway, and the status output disagrees with what happened

[Fluzko]

Part of #294.

Depends on: nothing.

What happens

Two related problems. One contradicts a written rule; the other is a reporting bug.

1. disable does not disable. A user writes [plugins] disable = ["some-crate"]. The crate's skills install anyway, and status reports it as declined. The precedence table in md/rfds/registry-centric-plugins/discovery-sync/README.md is explicit that disable wins unconditionally, and names a trusted registry among the things it beats:

Everything else (a trusted registry, auto-enable, an explicit use) is a way of saying a
plugin may run, and disable is the only way to say it may not

The configuration reference calls these "names that must never be enabled". When a plugin is reached through a registry's chained reference, that list is never consulted.

2. The status output is wrong even when no decision was recorded. With no [plugins] section at all, status says a crate is awaiting consent while its skills are already installed. A SessionStart message additionally tells the agent those plugins "stay off until the user consents", which is untrue for such a crate and which an agent may act on.

These need different fixes. Installing without asking is correct for a trusted registry: that is the point of a trust root, and the configuration reference says as much. Ignoring an explicit disable is not, and saying a plugin is off while it is on is not.

How to see it

# needs: cargo-agents, network, and an isolated SYMPOSIUM_HOME with the builtin
# registries off, an agent entry, and a [[registry]] path entry, same shape as the
# configuration in #289.
#
# IMPORTANT for step 2: the crate the registry entry chains to must ALSO be a direct
# dependency of the consumer project. Otherwise the awaiting-consent line never
# appears, because that classification only covers plugins embedded in the project's
# own dependencies.

# 1. an explicit refusal, ignored. append to the isolated config:
#      [plugins]
#      disable = ["<the chained crate>"]
SYMPOSIUM_HOME=/tmp/iso cargo agents sync
# -> installed skill <name> for claude -> <path>          the skills install
SYMPOSIUM_HOME=/tmp/iso cargo agents status
# -> <crate> <version> - declined (`[plugins] disable`)

# 2. no decision recorded at all: remove the [plugins] section entirely
SYMPOSIUM_HOME=/tmp/iso cargo agents sync      # -> skills installed
SYMPOSIUM_HOME=/tmp/iso cargo agents status
# -> <crate> <version> - found via dependency `<crate>`, awaiting consent
#      (`cargo agents use <crate>`)
#    while the skills are already on disk

Both reproduced with a source build, against a consumer project with dial9-viewer as a path dependency and a local [[registry]] entry chaining to it: disable = ["dial9-viewer"] still installs every skill, and status prints the awaiting-consent line with them on disk.

Done when

• A plugin named in disable does not install, however it was reached, matching the precedence table in the discovery design document.
• With no decision recorded, status does not describe a crate as awaiting consent while its skills are installed, and the session message does not tell the agent a plugin is off when it is on.
• Whatever replaces "awaiting consent" for a registry-activated crate makes clear it is active and why.

Also: the consent prompt for a crate a registry entry already serves is a no-op (added 2026-09-18)

Found while verifying dial9-rs/dial9#917. Once the dial9 crate ships skills/, every project that depends on it is offered dial9 X.Y.Z - found via dependency dial9, awaiting consent, although the registry entry named dial9 already installs those skills. Accepting changes nothing: active_plugins skips an enabled crate whose normalized name a registry entry already provides (src/plugins.rs, the registry-name skip before the worklist). Declining writes disable = ["dial9"], which only discovery consults, so the chained install proceeds anyway, the case in point 1 above. The user answers a question whose answer has no effect either way. The same happens for any crate that both ships skills and is served by a registry entry of the same name.