paperclipai/paperclip · error
PRP Codex transport does not expose provider method ${method
Error message
PRP Codex transport does not expose provider method ${method} What it means
The PRP Codex transport implements a fixed allowlist of provider JSON-RPC methods. When a caller requests a method outside that allowlist, the transport refuses with this message naming the unsupported method. It guards against silently forwarding unimplemented requests to the Codex runner.
Source
Thrown at packages/paperclip-runner/src/live/runnerd-codex-transport.ts:3511
!this.#checkpointProviderIdentityConfirmed
) {
const snapshot = await this.#commandResult("session.snapshot", {});
this.#confirmCheckpointProviderIdentity(
snapshot,
"authenticated session.snapshot",
);
}
return {
thread: {
id: this.#threadId,
sessionId: this.#sessionId,
...(this.#providerIdentity === null
? {}
: { providerIdentity: structuredClone(this.#providerIdentity) }),
},
};
}
throw new Error(
`PRP Codex transport does not expose provider method ${method}`,
);
}
notify(_method: string, _params?: Record<string, unknown>): void {}
notifications(): AsyncIterable<CodexRpcNotification> {
return this.#queue;
}
setServerRequestHandler(handler: CodexServerRequestHandler): void {
this.#handler = handler;
}
async #awaitWarmRunAttachmentReady(): Promise<void> {
// Remote runner ingress already has a bounded reconnect budget. Reuse the
// same budget here so a transient tunnel reconnect cannot trip the shorter
// generic command timeout and replace an otherwise healthy warm runner.View on GitHub (pinned to 01ad858492)
Solutions
- Check the method name for typos against the allowlist in the switch statement above line 3511
- Upgrade @paperclip/runner (and paperclip-runner) to a version whose Codex transport supports the requested method
- Route the call through the runner core command queue instead of the provider-method entry point
- If the method is genuinely needed, extend the transport's allowlist to handle it explicitly
Example fix
// before
await transport.request('codex/newExperimentalMethod', params);
// after
const supported = ['codex/turn', 'codex/attach', 'codex/cancel'];
if (!supported.includes(method)) throw new Error(`unsupported method: ${method}`);
await transport.request(method, params); Defensive patterns
Strategy: validation
Validate before calling
const SUPPORTED_PROVIDER_METHODS = new Set(['codex/turn','codex/attach','codex/cancel']);
function assertSupported(method) {
if (!SUPPORTED_PROVIDER_METHODS.has(method)) throw new Error(`unsupported provider method: ${method}`);
} Prevention
- Keep a central list of provider methods your code calls and diff it against the transport's allowlist on upgrades
- Wrap provider method calls in a helper that validates the method name first
- Pin transport and Codex versions together and re-check the allowlist when bumping either
When it happens
Trigger: Calling the transport's provider request entry point (the method whose switch ends at line 3511) with a method string not handled by the allowlist, e.g. a custom/experimental Codex method or a typo like 'codex.turnFoo'.
Common situations: Upgrading or downgrading Codex so new methods exist that this pinned transport version does not know; typos in method names; plugins invoking provider methods directly that only the runner core supports.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- device-login promotion: the account identifier cannot form a
- codex auth cache: account_id is not a valid account handle
- codex auth cache: account-home directory no longer exists; r
- Paperclip Runner currently supports Codex only with codexPer
- paperclip_runner_codex_permission_mode_unqualified
AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10).
Data as JSON: /api/errors/e51eb5ad7f573b39.
Report an issue: GitHub.