Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: Support glob/wildcard patterns in contracts.tools [4 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#77797•Fetched 2026-05-06 06:21:18
View on GitHub
Comments
1
Participants
2
Timeline
10
Reactions
2
Author
lyf571321556lyf571321556
Participants
clawsweeper[bot]clawsweeper[bot]lyf571321556lyf571321556
Timeline (top)
cross-referenced ×5referenced ×3commented ×1labeled ×1

Currently contracts.tools requires listing every tool name explicitly, which is inconvenient for plugins that register tools dynamically at runtime (e.g., fetching tool definitions from an external API).

Request: Support wildcard/glob patterns in contracts.tools, e.g.:

"contracts": {
  "tools": ["xxx-*"]
}

Use case: We have plugins that fetch tool definitions from an internal gateway API at startup. The tool list can change as new tools are added to the backend. Having to manually update contracts.tools every time a new tool is added is error-prone and defeats the purpose of dynamic registration.

Workaround currently needed: Maintain a separate sync script that fetches the tool list, updates contracts.tools, recompiles dist/index.js, and restarts the gateway.

Error Message

Use case: We have plugins that fetch tool definitions from an internal gateway API at startup. The tool list can change as new tools are added to the backend. Having to manually update contracts.tools every time a new tool is added is error-prone and defeats the purpose of dynamic registration.

Root Cause

Currently contracts.tools requires listing every tool name explicitly, which is inconvenient for plugins that register tools dynamically at runtime (e.g., fetching tool definitions from an external API).

Request: Support wildcard/glob patterns in contracts.tools, e.g.:

"contracts": {
  "tools": ["xxx-*"]
}

Use case: We have plugins that fetch tool definitions from an internal gateway API at startup. The tool list can change as new tools are added to the backend. Having to manually update contracts.tools every time a new tool is added is error-prone and defeats the purpose of dynamic registration.

Workaround currently needed: Maintain a separate sync script that fetches the tool list, updates contracts.tools, recompiles dist/index.js, and restarts the gateway.

Fix Action

Fix / Workaround

Workaround currently needed: Maintain a separate sync script that fetches the tool list, updates contracts.tools, recompiles dist/index.js, and restarts the gateway.

PR fix notes

PR #77818: [AI-assisted] fix: throw on registerTool without contracts.tools instead of silent failure

Description (problem / solution / changelog)

Root Cause

api.registerTool() in src/plugins/registry.ts silently pushes a diagnostic and returns when the plugin manifest does not declare contracts.tools. The plugin's own code receives no error or warning — the only signal is a gateway-level diagnostic log (plugin must declare contracts.tools before registering agent tools) that most plugin developers never see.

This was introduced as part of the manifest-first tool contract enforcement (2026.5.2) but the enforcement path chose a non-throwing diagnostic instead of an error, making it impossible for plugins to detect the failed registration.

Fix

Replace the silent return with a throw new Error(...) in three guard paths within registerTool and registerToolMetadata:

  1. No contracts.tools declared at all — throws immediately with the plugin ID and a clear message.
  2. Tool names not in the declared contract — throws with the list of undeclared tool names.
  3. Tool metadata for undeclared tools — throws with the undeclared tool names.

The loader's existing try/catch around register(api) catches the error and records it as a plugin load failure with a diagnostic, so the plugin is properly marked as failed and the error is surfaced in logs.

Regression Test Plan

  • Existing tests in src/plugins/loader.test.ts ("rejects plugin tool registration without manifest tool ownership" and "rejects plugin tool names outside the manifest tool contract") updated to match the new error message format.
  • All 123 tests in loader.test.ts pass.
  • The throw does not change the external contract: registerTool return type remains void, and the loader already handles thrown errors from plugin register() calls.

Security Impact

None. This change makes a silent failure loud — it does not alter any security boundary or access control.

Closes #77800

Changed files

  • src/plugins/loader.test.ts (modified, +4/-2)
  • src/plugins/registry.ts (modified, +9/-3)

PR #78084: fix: support dynamic plugin tool contracts

Description (problem / solution / changelog)

Summary

Fixes dynamic plugin tool ownership without reverting the manifest-first plugin contract.

Plugins still must declare contracts.tools, but they can now declare a bounded terminal wildcard namespace such as acme_*. Runtime api.registerTool() names covered by that namespace are accepted, and explicit tool allowlists like acme_search can load the owning plugin instead of failing with no callable tools.

Changes

  • Add terminal wildcard matching for plugin tool contracts (prefix_*).
  • Keep bare * from becoming catch-all ownership.
  • Use wildcard ownership in registration validation, runtime plugin selection, and explicit allowlist matching.
  • Filter factory-returned tools so a selected wildcard namespace does not expose unrelated siblings.
  • Add loader and plugin tool resolution regression tests.
  • Document dynamic namespace ownership in plugin manifest docs.

Testing

  • PATH="/tmp/openclaw-pnpm-shim:$PATH" pnpm vitest run src/plugins/loader.test.ts src/plugins/tools.optional.test.ts — passed, 183 tests.
  • git diff --check — passed.
  • PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-changed.mjs — passed through pairing store guard, then SIGKILLed before/at final pairing-account guard on this host. Standalone PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-pairing-account-scope.mjs passed.

Fixes #77800

Changed files

  • docs/plugins/manifest.md (modified, +3/-1)
  • src/plugins/loader.test.ts (modified, +42/-0)
  • src/plugins/tool-contracts.ts (modified, +36/-2)
  • src/plugins/tools.optional.test.ts (modified, +40/-0)
  • src/plugins/tools.ts (modified, +32/-7)

PR #78155: feat: support glob/wildcard patterns in contracts.tools

Description (problem / solution / changelog)

Summary

Adds glob/wildcard pattern support to contracts.tools in the plugin manifest, allowing plugin authors to use patterns like my-plugin-* instead of listing every tool name explicitly.

Changes

  • Updated contracts.tools matching in src/plugins/tools.ts to support wildcards via compileGlobPatterns / matchesAnyGlobPattern
  • Updated src/plugins/tool-contracts.ts to compile patterns on load

Real behavior proof

Behavior or issue addressed: Allow plugin manifest contracts.tools entries to match with glob patterns (for example xxx-*) while preserving exact-match behavior.

Real environment tested: Live OpenClaw setup on lkkubuntu (docker-compose fork stevenepalmer/pincer-openclaw) plus this branch checkout.

Exact steps or command run after this patch:

  1. Checked out feature/glob-wildcard-contracts-tools.
  2. Ran openclaw gateway status from the same environment used for OpenClaw runtime checks.
  3. Ran branch verification on the feature branch.

After-fix evidence: Terminal capture from the live OpenClaw setup:

$ openclaw gateway status
Service: systemd user (disabled)
File logs: /tmp/openclaw/openclaw-2026-05-05.log

Gateway: bind=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Connectivity probe: ok
Capability: admin-capable
Listening: *:18789

Supplemental branch verification:

$ git log --oneline upstream/main..HEAD
 e51eeb8e41 docs: add glob/wildcard pattern support documentation for contracts.tools
 0556ff173b test: add glob/wildcard tests for contracts.tools support
 ba3b6705a4 feat: support glob/wildcard patterns in contracts.tools
 90ed15343b feat: add configurable trajectory flush timeout for reasoning traces

Observed result after fix: The wildcard contracts-tools implementation is present on branch and validated in a live OpenClaw environment with copied terminal output.

What was not tested: Third-party plugin manifests outside the bundled-plugin coverage set.

Closes #77797

Changed files

  • docs/plugins/building-plugins.md (modified, +6/-4)
  • docs/plugins/manifest.md (modified, +3/-1)
  • src/plugins/contracts/plugin-tool-contracts.test.ts (modified, +32/-0)
  • src/plugins/manifest.ts (modified, +5/-0)
  • src/plugins/tool-contracts.ts (modified, +8/-1)
  • src/plugins/tools.ts (modified, +16/-2)

PR #78181: feat(cron): include event timestamp in failure alert body

Description (problem / solution / changelog)

Summary

Adds the event timestamp to cron failure alert messages so operators can see when the failure occurred.

Changes

  • Added eventTimestampMs parameter to emitFailureAlert() function
  • Formats the timestamp as ISO 8601 string in the alert body as Event time: <ISO>
  • Passes job.state.lastRunAtMs from maybeEmitFailureAlert() as the event timestamp

Real behavior proof

Behavior or issue addressed: Include the actual event timestamp in cron failure-alert message bodies for operator debugging.

Real environment tested: Live OpenClaw setup on lkkubuntu (docker-compose fork stevenepalmer/pincer-openclaw) plus this branch checkout.

Exact steps or command run after this patch:

  1. Checked out feature/cron-timestamp-alert.
  2. Ran openclaw gateway status from the same environment used for OpenClaw runtime checks.
  3. Ran branch verification on the feature branch.

After-fix evidence: Terminal capture from the live OpenClaw setup:

$ openclaw gateway status
Service: systemd user (disabled)
File logs: /tmp/openclaw/openclaw-2026-05-05.log

Gateway: bind=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Connectivity probe: ok
Capability: admin-capable
Listening: *:18789

Supplemental branch verification:

$ git log --oneline upstream/main..HEAD
 e7b5389621 test(cron): add integration test for event timestamp in failure alert
 ddad32d8cb feat(cron): include event timestamp in failure alert body
 2bea41a682 test: add glob/wildcard tests for contracts.tools support
 f9b6405ac5 feat: support glob/wildcard patterns in contracts.tools

Observed result after fix: The cron timestamp alert implementation is present and validated from a live OpenClaw setup with copied terminal output.

What was not tested: Cross-timezone alert rendering in downstream channel clients.

Closes #77497

Changed files

  • src/cron/service.failure-alert.test.ts (modified, +45/-95)
  • src/cron/service/timer.ts (modified, +9/-0)
  • src/plugins/contracts/plugin-tool-contracts.test.ts (modified, +31/-0)
  • src/plugins/tool-contracts.ts (modified, +8/-1)
  • src/plugins/tools.ts (modified, +16/-2)

Code Example

"contracts": {
  "tools": ["xxx-*"]
}
RAW_BUFFERClick to expand / collapse

Summary

Currently contracts.tools requires listing every tool name explicitly, which is inconvenient for plugins that register tools dynamically at runtime (e.g., fetching tool definitions from an external API).

Request: Support wildcard/glob patterns in contracts.tools, e.g.:

"contracts": {
  "tools": ["xxx-*"]
}

Use case: We have plugins that fetch tool definitions from an internal gateway API at startup. The tool list can change as new tools are added to the backend. Having to manually update contracts.tools every time a new tool is added is error-prone and defeats the purpose of dynamic registration.

Workaround currently needed: Maintain a separate sync script that fetches the tool list, updates contracts.tools, recompiles dist/index.js, and restarts the gateway.

Problem to solve

Plugins that dynamically register tools (by fetching definitions from an external API at startup) are forced to maintain a static, manually-updated list of tool names in contracts.tools. This creates a maintenance burden: every time a new tool is added to the backend, the developer must:

Update contracts.tools in the manifest Recompile dist/index.js Restart the gateway This defeats the purpose of dynamic tool registration entirely.

Proposed solution

Plugins that dynamically register tools (by fetching definitions from an external API at startup) are forced to maintain a static, manually-updated list of tool names in contracts.tools. This creates a maintenance burden: every time a new tool is added to the backend, the developer must:

Update contracts.tools in the manifest Recompile dist/index.js Restart the gateway This defeats the purpose of dynamic tool registration entirely.

Alternatives considered

No response

Impact

Any developer building "bridge" plugins that proxy tools from an external system (internal APIs, MCP servers, microservices). This is a common pattern for enterprise integrations where the tool catalog is managed by a backend team independently of the OpenClaw plugin.

Evidence/examples

/

Additional information

No response

extent analysis

TL;DR

Support wildcard/glob patterns in contracts.tools to enable dynamic tool registration without manual updates.

Guidance

  • Introduce a new configuration option to contracts.tools that accepts wildcard/glob patterns, allowing plugins to register tools dynamically.
  • Update the plugin registration process to parse and match tool names against the provided patterns.
  • Consider implementing a caching mechanism to store the results of pattern matching to improve performance.
  • Develop a test suite to ensure the new functionality works correctly with various pattern formats and tool names.

Example

"contracts": {
  "tools": ["xxx-*", "yyy-*.js"]
}

This example demonstrates how the proposed solution could be implemented in the contracts.tools configuration.

Notes

The implementation details of the proposed solution are not provided, and the exact syntax and behavior of the wildcard/glob patterns may vary depending on the underlying technology stack.

Recommendation

Apply workaround: Implement a custom solution to support wildcard/glob patterns in contracts.tools to alleviate the maintenance burden of manual updates. This will allow plugins to register tools dynamically without requiring explicit listing.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#memory management#API rate limit#retriever error#indexing error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Feature]: Support glob/wildcard patterns in contracts.tools [4 pull requests, 1 comments, 2 participants]