#core pr vs plugins

1 messages · Page 1 of 1 (latest)

olive schooner
#

Thinking through the plugin boundary more, I think #74783 and #74799 probably split differently.

For #74783, I don’t see a clean pure-plugin version today. Plugins can register their own gateway RPC/HTTP surfaces, but they do not currently own or see the authenticated websocket keepalive state. BunsDev already added the core 25s authenticated Gateway WebSocket ping in https://github.com/openclaw/openclaw/pull/76111, fixing https://github.com/openclaw/openclaw/issues/70991, which feels like the right layer for this. What #74783 adds on top is tracking the ping/pong result per authenticated client and surfacing rttMs / lastHeartbeatAt in the standard health response. A plugin could expose a parallel health method, but it could not provide real per-client RTT / heartbeat data unless core tracks and exposes that connection health first.

For #74799, I think this can probably be reshaped into a smaller core extension-point plus plugin-owned policy instead of an XL core feature PR.

The core piece would be something like:

  • sessions.create / sessions.patch can carry bounded plugin-namespaced session metadata.
  • a before_session_create hook can block or patch session creation before the session is written.
  • an optional session_created observation hook fires after write.
  • before_tool_call hook context includes enough runtime info to enforce policy safely, e.g. sessionKey, sessionId, runId, workspaceDir, containerWorkdir.

Then a plugin can own the opinionated behavior:

  • validate/store runtime policy metadata on session create.
  • enforce allowed/disallowed tools, allowed/denied paths, and command allowlists in before_tool_call.
  • optionally expose plugin-prefixed methods like session-envelope.get/update.

That would avoid adding downstream-specific runtime policy directly to OpenClaw core, while still giving tools built on top of OpenClaw a stable way to integrate without carrying private patches.