openclaw - 💡(How to fix) Fix RFC: allowConversationAccess as plugin manifest field (replaces 2 schema patches) [1 comments, 2 participants]

Problem statement

The allowConversationAccess flag is set in ~/.openclaw/openclaw.json per-plugin under plugins.entries.<id>.hooks.allowConversationAccess: true. The flag is gated by config schema validation; non-bundled plugins must explicitly opt in or the gateway rejects their agent_end typed-hook subscriptions.

The PRoblem: the gateway's config schema doesn't know about the field unless explicitly extended. Smarter-Claw maintains TWO patches just to make this opt-in possible:

• installer/patches/core/schema-allow-conversation-access.diff (~12 LOC, JSON schema)
• installer/patches/core/zod-schema-allow-conversation-access.diff (~12 LOC, Zod schema)

Both patches add the same field declaration in two parallel locations — a recurring pattern that should be obviated.

Proposed change

Make allowConversationAccess a declared field in the plugin manifest (openclaw.plugin.json) instead of in the host config:

{
  "id": "smarter-claw",
  "name": "Smarter Claw",
  "permissions": {
    "conversationAccess": true
  }
}

The gateway reads the manifest at plugin load. If permissions.conversationAccess is true AND the plugin requests agent_end (or other conversation-access-gated hook), it's allowed. No host config flag needed; no schema patches needed.

For backward compatibility, the existing config flag continues to work (and overrides manifest if both present).

Implementation sketch

// src/plugins/registry.ts (or similar)
function isConversationAccessAllowed(plugin: PluginManifest, config: PluginEntryConfig): boolean {
  if (config?.hooks?.allowConversationAccess === true) return true; // existing path
  if (plugin.permissions?.conversationAccess === true) return true; // NEW
  return false;
}

Backward compatibility

Fully additive. Plugins that already set the config flag continue to work. New plugins can declare in manifest instead.

What this saves Smarter-Claw

• Delete installer/patches/core/schema-allow-conversation-access.diff
• Delete installer/patches/core/zod-schema-allow-conversation-access.diff
• Move permission declaration to where it belongs (the plugin's own manifest)

Why this matters beyond Smarter-Claw

This pattern recurs for any future capability gates. Currently each gate requires a parallel pair of patches (Zod + JSON schema). Manifest-declared permissions scale linearly without patch overhead — and put the permission disclosure in the plugin developer's own file (where security review can find it) rather than in the operator's config (where it's invisible).

Tests proposed

• Plugin with permissions.conversationAccess: true in manifest can subscribe to agent_end without any config flag
• Plugin without the manifest field AND no config flag → existing rejection behavior
• Plugin with both → manifest value used (fallback to config if missing)

Cross-link

Smarter-Claw RFC series:

• openclaw/openclaw#71260 (mergeSessionEntryWithPolicy)
• openclaw/openclaw#71426 (sessions.patch extension hook)
• openclaw/openclaw#71427 (tool-event subscription)