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

  1. Check the method name for typos against the allowlist in the switch statement above line 3511
  2. Upgrade @paperclip/runner (and paperclip-runner) to a version whose Codex transport supports the requested method
  3. Route the call through the runner core command queue instead of the provider-method entry point
  4. 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

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


AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10). Data as JSON: /api/errors/e51eb5ad7f573b39. Report an issue: GitHub.