Summary

@paperclipai/adapter-openclaw-gateway adds a root-level paperclip object to every req agent payload, but published OpenClaw builds reject that field during agent param validation with:

invalid agent params: at root: unexpected property 'paperclip'

This appears to break Paperclip's documented openclaw_gateway integration end to end, even when onboarding/auth/device pairing all succeed.

Versions tested

OpenClaw:

• stable: 2026.4.15 (041266a)
• beta: 2026.4.19-beta.2 (dc3df91)

Paperclip / adapter:

• [email protected]
• @paperclipai/[email protected]

Also spot-checked older canaries, all of which still add the same root-level paperclip field:

• 2026.415.0-canary.7
• 2026.413.0-canary.3
• 2026.411.0-canary.8
• 2026.409.0-canary.4

What the adapter documents

The published adapter docs say the gateway flow is:

1. connect
2. req agent
3. req agent.wait

They also explicitly document:

paperclip (object): standardized Paperclip context added to every gateway agent request

And the published adapter code does:

const agentParams = {
  ...payloadTemplate,
  message,
  sessionKey,
  idempotencyKey: ctx.runId,
};
...
agentParams.paperclip = paperclipPayload;

Actual result

The gateway connection/auth path succeeds, then the agent request is rejected:

[openclaw-gateway] connecting to ws://127.0.0.1:18789/
[openclaw-gateway] connected protocol=3
[openclaw-gateway] request failed: invalid agent params: at root: unexpected property 'paperclip'

Redacted outbound payload excerpt:

{
  "message": "Paperclip wake event for a cloud adapter...",
  "sessionKey": "paperclip",
  "idempotencyKey": "1fef9bd2-6cab-454d-a480-d3193e9ba378",
  "paperclip": {
    "runId": "1fef9bd2-6cab-454d-a480-d3193e9ba378",
    "agentId": "...",
    "companyId": "..."
  },
  "timeout": 120000
}

Direct validator repro

I also tested the published OpenClaw validators directly from both the stable and beta npm packages with a minimal payload containing the root-level paperclip field.

Both fail identically with additional-properties validation:

[
  {
    "instancePath": "",
    "schemaPath": "#/additionalProperties",
    "keyword": "additionalProperties",
    "params": {
      "additionalProperty": "paperclip"
    },
    "message": "must NOT have additional properties"
  }
]

Expected

One of these should be true:

1. OpenClaw req agent should accept the documented root-level paperclip metadata block from the published Paperclip gateway adapter, or
2. the published Paperclip adapter/docs should be updated to use a supported metadata path instead of adding paperclip at the root of agent params.

Why this seems important

This is easy to miss because earlier onboarding issues can fail first, but once onboarding/auth/device-pairing succeed, the published Paperclip/OpenClaw path appears blocked at runtime by a schema mismatch between the two published packages.

If useful, I can also provide the exact minimal validator script used for the stable/beta check.