Problem

After upgrading OpenClaw (e.g. via doctor --fix or openclaw update), the hooks.allowConversationAccess setting for the community plugin rl-training-headers is silently reset. The plugin entry in plugins.entries loses its hooks sub-block.

The field is also impossible to set via gateway config.patch — the call fails with:

gateway config.patch cannot change protected config paths: hooks.allowConversationAccess

This means after every upgrade, rl-training-headers is suddenly broken again with 0 error/warning from the upgrade process itself — the plugin shows as enabled but never activates.

Impact

The plugin uses two hooks:

• before_prompt_build — sets sessionId + turnType (OK without hooks.allowConversationAccess)
• agent_end — clears per-run state so headers don't leak across sessions

agent_end is silently blocked without hooks.allowConversationAccess. Result:

• pendingHeaders never cleared → stale sessionId leaks into next session's API requests
• Historical: 5,535 blocked agent_end events accumulated across 2 weeks
• Plugin reports "activated" but state cleanup is broken

⚠️ Updated analysis: before_prompt_build is actually controlled by allowPromptInjection (separate gate), NOT allowConversationAccess. So the pluginhook failure is specifically in agent_end cleanup.

Source

Plugin upstream: https://github.com/Gen-Verse/OpenClaw-RL (extensions/rl-training-headers/)

Note: The upstream TS source uses AsyncLocalStorage (auto-cleanup per async context, no agent_end needed). The local CommonJS compile uses a module-level pendingHeaders variable that requires agent_end to clear.

Root Cause

1. v2026.4.22 introduced Hook Policy: non-bundled plugins require explicit plugins.entries.<id>.hooks.allowConversationAccess: true to access conversation-sensitive hooks (agent_end, llm_input, llm_output, etc.)
2. hooks.allowConversationAccess is a protected config path — config.patch cannot write it
3. During upgrade operations (doctor --fix, openclaw update), the upgrade process rewrites plugins.entries from scratch, dropping any custom hooks blocks for plugins it doesn't know
4. Community/local plugins are not recognized by the upgrade tooling, so their config is replaced with just enabled: true, config: {}

What Was Tried

Current Workaround

Manually edit ~/.openclaw/openclaw.json after each upgrade:

"plugins": {
  "entries": {
    "rl-training-headers": {
      "enabled": true,
      "config": {},
      "hooks": {
        "allowConversationAccess": true
      }
    }
  }
}

Suggested Fixes (any of these would help)

1. Document the workaround clearly in the Hook Policy docs, including the exact JSON to add and which hooks are affected
2. Recognize local/community plugins in upgrade tooling — don't overwrite hooks blocks for plugin IDs not known to the upgrade process
3. Allow config.patch to set hooks.allowConversationAccess — it's a deliberate runtime policy choice by the user, not something that needs protection
4. Add a warning during upgrade if plugins.entries will be modified, listing which plugins are affected
5. Support allowConversationAccess in plugin manifest (openclaw.plugin.json) so the plugin can declare its own requirements (RFC #71428 and #71621)
6. Bundle rl-training-headers in OpenClaw core so it gets proper config management

Environment

• OpenClaw: v2026.5.9-beta.1 (macOS, Gateway on launchd)
• Plugin: rl-training-headers (community, from https://github.com/Gen-Verse/OpenClaw-RL)
• Related: RFC #71428 (allowConversationAccess as plugin manifest field)
• Related: Bug #71621 (validator rejects plugins.entries.*.hooks.allowConversationAccess)