Summary
openclaw workboard dispatch always fails with missing scope: operator.admin, even though the workboard.cards.dispatch gateway method is registered as operator.write and the docs state dispatch requires operator.write. This makes headless / CLI dispatch impossible — only the dashboard "Run" works, because paired operator devices carry operator.admin.
Version
OpenClaw 2026.6.5. Gateway: local, token auth.
Steps to reproduce
- Enable the
workboard plugin.
- Create a card and set it to
ready.
- Run
openclaw workboard dispatch.
Result: missing scope: operator.admin
Expected: the dispatch runs and starts a worker (docs say the method requires operator.write, which the CLI's shared-secret token carries).
Root cause (traced in the 2026.6.5 dist)
workboard.cards.dispatch is registered with { scope: operator.write } and is not in the reserved-admin namespaces (exec.approvals. / config. / wizard. / update.).- But
resolveScopedMethod() looks the method up in getPluginRegistryState().activeRegistry.gatewayMethodDescriptors and finds no descriptor for it, so it returns undefined.
authorizeOperatorScopesForMethod() then does resolveRequiredOperatorScopeForMethod(method) ?? "operator.admin" — the unclassified-method fallback defaults the required scope to operator.admin.- The
openclaw workboard dispatch CLI connects requesting only ["operator.write","operator.read"], so the (incorrect) admin requirement rejects it. The dashboard only works because operator devices hold operator.admin, which short-circuits the check.
Net: plugin gateway methods registered at runtime appear to be missing from the active-registry snapshot used for scope classification, so they silently require operator.admin instead of their declared scope.
Workaround
Call the method through the generic gateway caller, which requests the full default operator scope set (including admin) for an unclassified method:
openclaw gateway call workboard.cards.dispatch --params '{}'
Related (same family — internal/plugin gateway calls vs. scope resolution)
Suggested fix
Either (a) ensure plugin-registered gateway-method descriptors (with their declared scope) populate the active-registry snapshot consulted by resolveScopedMethod, or (b) have the workboard dispatch CLI request the method's declared scope. A general fix to (a) would also prevent this class from recurring for other plugin methods (cf. the memory-core history above).
Summary
openclaw workboard dispatchalways fails withmissing scope: operator.admin, even though theworkboard.cards.dispatchgateway method is registered asoperator.writeand the docs state dispatch requiresoperator.write. This makes headless / CLI dispatch impossible — only the dashboard "Run" works, because paired operator devices carryoperator.admin.Version
OpenClaw
2026.6.5. Gateway: local, token auth.Steps to reproduce
workboardplugin.ready.openclaw workboard dispatch.Result:
missing scope: operator.adminExpected: the dispatch runs and starts a worker (docs say the method requires
operator.write, which the CLI's shared-secret token carries).Root cause (traced in the 2026.6.5 dist)
workboard.cards.dispatchis registered with{ scope: operator.write }and is not in the reserved-admin namespaces (exec.approvals./config./wizard./update.).resolveScopedMethod()looks the method up ingetPluginRegistryState().activeRegistry.gatewayMethodDescriptorsand finds no descriptor for it, so it returnsundefined.authorizeOperatorScopesForMethod()then doesresolveRequiredOperatorScopeForMethod(method) ?? "operator.admin"— the unclassified-method fallback defaults the required scope tooperator.admin.openclaw workboard dispatchCLI connects requesting only["operator.write","operator.read"], so the (incorrect) admin requirement rejects it. The dashboard only works because operator devices holdoperator.admin, which short-circuits the check.Net: plugin gateway methods registered at runtime appear to be missing from the active-registry snapshot used for scope classification, so they silently require
operator.admininstead of their declared scope.Workaround
Call the method through the generic gateway caller, which requests the full default operator scope set (including admin) for an unclassified method:
Related (same family — internal/plugin gateway calls vs. scope resolution)
memory-coredream-promotion cron failingmissing scope: operator.admin(closed) — same root-cause shape for a different plugin method.sessions_spawnfailingmissing scope: operator.writedespite a full-scope token (open).Suggested fix
Either (a) ensure plugin-registered gateway-method descriptors (with their declared
scope) populate the active-registry snapshot consulted byresolveScopedMethod, or (b) have theworkboard dispatchCLI request the method's declared scope. A general fix to (a) would also prevent this class from recurring for other plugin methods (cf. the memory-core history above).