Summary

Plugin-registered textTransforms (via api.registerTextTransforms()) are never applied to agent prompts or system prompts in the main gateway process. The transforms are registered successfully (confirmed by log output), but the reading side always returns empty.

Root Cause

resolveRuntimeTextTransforms() in src/plugins/text-transforms.runtime.ts relies entirely on loadPluginRuntime() to access the active plugin registry:

export function resolveRuntimeTextTransforms(): PluginTextTransforms | undefined {
  const registry = loadPluginRuntime()?.getActivePluginRegistry();
  // ...
}

loadPluginRuntime() tries to require("./runtime.js") (and "./runtime.ts"). In the main openclaw process, dist/runtime.js does not exist — only the content-hashed dist/runtime-<hash>.js does. So require("./runtime.js") always throws, the catch swallows it, and loadPluginRuntime() returns null.

Result: resolveRuntimeTextTransforms() always returns undefined, and backendResolved.textTransforms is always empty.

Evidence

# Plugin registers transforms successfully:
[plugins] [my-plugin:transforms] text transforms registered (input: 2, output: 0)

# But system prompt / prompts still contain the un-replaced strings

Confirmed with Node.js:

import { createRequire } from "node:module";
const require = createRequire("/path/to/openclaw/dist/provider-runtime-<hash>.js");
require("./runtime.js"); // → Error: Cannot find module './runtime.js'

Why loadPluginRuntime() exists

The require("./runtime.js") pattern makes sense for external plugins (separate npm packages) that don't know the content-hash of the runtime file. They need a stable path to cross the module boundary and share singleton state.

However, in the main process, provider-runtime-<hash>.js is already bundled together with the runtime module and can import from it directly via ES module imports.

Fix

In src/plugins/text-transforms.runtime.ts, add a direct import of getActivePluginRegistry from the runtime module. Use it as the primary path (works in the main bundle), and keep loadPluginRuntime() as a fallback (for external plugin contexts):

import { getActivePluginRegistry } from "./runtime.js"; // resolved correctly at build time

export function resolveRuntimeTextTransforms(): PluginTextTransforms | undefined {
  // Direct import works in main process (bundled together)
  // loadPluginRuntime() fallback works in external plugin contexts
  const registry = getActivePluginRegistry() ?? loadPluginRuntime()?.getActivePluginRegistry();
  const pluginTextTransforms = Array.isArray(registry?.textTransforms)
    ? registry.textTransforms.map((entry) => entry.transforms)
    : [];
  return mergePluginTextTransforms(...pluginTextTransforms);
}

Affected versions

• Confirmed on 2026.4.10 (dist: 44e5b62)
• Root cause present in current main branch (src/plugins/text-transforms.runtime.ts)

Impact

All plugins using api.registerTextTransforms() — the registered transforms are silently ignored. Affects prompt sanitization, obfuscation of special tags (e.g. [[reply_to_current]]), and any text replacement configured via plugin textTransforms config.