[Bug] RemoteTrigger.run MCP action returns HTTP 400 — trigger_id sent in body instead of URL path

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

---
report_type: External Bug Report (Anthropic)
target: Anthropic Claude Code Routines (CCR) MCP tool
component: RemoteTrigger.run action
severity: P2 / Medium (operationally workaround-able via web UI; blocks programmatic ad-hoc validation flows)
date: 2026-04-29
reporter: dman1809 (Dominic A. Newman) via Claude Code session
environment:

• MCP tool surface: RemoteTrigger (CCR trigger management)
• Working actions: create, update, get, list (all return HTTP 200 with expected payloads)
• Broken action: run (consistent HTTP 400 across all attempted invocations)
• Account: dman1809 (account_uuid e3e96075-1623-454a-9644-cd77153b311b)

---

MCP Tool Bug — RemoteTrigger.run Action Returns HTTP 400

Summary

The MCP tool's RemoteTrigger.run action injects the trigger_id parameter
into the HTTP request body. The Anthropic CCR API for the run endpoint
expects trigger_id in the URL path only — body parameters trigger a
strict-validator rejection. Every invocation of the run action via the
MCP tool fails with HTTP 400 and an
invalid_request_error: trigger_id: Extra inputs are not permitted message.

The local MCP tool's pre-flight validator also rejects calls that omit
trigger_id from the request, creating a no-win situation: include
trigger_id and the API rejects it; omit it and the local tool rejects it.
Net effect: the run action is uninvocable from the MCP surface.

Impact

• Operational impact: Medium. CCR routine triggers cannot be ad-hoc

fired programmatically via the MCP tool surface.

• Workflow affected: Validation of CCR trigger configuration changes

(e.g. RemoteTrigger.update followed by ad-hoc run to confirm the new
config takes effect before relying on the natural cron). This is a common
ops pattern any time a trigger's session_context, prompt, or sources are
modified.

• Consumers affected: Any user of the MCP tool's CCR surface attempting

programmatic trigger validation.

• Severity rationale: P2 (Medium) because:

1. Workaround exists (claude.ai web UI manual fire — see below)
2. Natural cron-triggered fires are unaffected (the bug is in the

run-action client surface only; backend fires correctly)

1. Other RemoteTrigger.* actions work, so the rest of the CCR config

flow is functional

Workaround

For ad-hoc trigger fires, use the claude.ai web UI:

1. Navigate to the routines page on claude.ai
2. Click on the routine name (NOT the "Run once" affordance — that is for

one-shot scheduled tasks; recurring routines have a "Run now" / "Test"
affordance on the routine's detail page)

1. Click the manual-fire button on the detail page

Verified working for trigger trig_01SqtbGaT8uZqFSjiTdYpVsZ via web UI
during today's ops session.

Suggested Fix

Modify the MCP tool's RemoteTrigger.run action to:

1. Construct the request as POST /v1/code/triggers/{trigger_id}/run with

trigger_id substituted into the URL path

1. Send empty {} request body by default (or the consumer-provided body

for run-time overrides if the API supports them)

1. Local validator should accept trigger_id as the action's required

input parameter, then translate it to URL-path placement during request
construction (rather than letting it pass through into the body
payload)

The same translation pattern is presumably already in place for get and
update, both of which are documented as path-parameter forms and both of
which work correctly. The fix is likely to copy that translation to the
run code path.

What Should Happen?

Reporter Context

This bug surfaced during a routine ops flow: a RemoteTrigger.update was
applied to two scheduled triggers to extend their sources list, and an
ad-hoc run was attempted to validate that the updated config was
clone-reachable before the natural cron fire. The update calls succeeded
(HTTP 200, both payloads correct); only the validation run could not be
issued.

Workaround via the web UI is sufficient for this session. Reporting so the
programmatic surface can be fixed.

Happy to provide additional reproduction context, full request/response
captures, or session URLs if helpful — request IDs from the failed
attempts are included above for log correlation on Anthropic's side.

Error Messages/Logs

## Related Observations

What works correctly in the same MCP tool surface (verified today):
- `RemoteTrigger.create` (verified earlier on this account during initial
  trigger setup)
- `RemoteTrigger.update` — HTTP 200, payload reflects the modification with
  all other fields preserved
- `RemoteTrigger.get` — HTTP 200, returns full trigger config
- `RemoteTrigger.list` — HTTP 200, returns the account's trigger list

What's broken:
- `RemoteTrigger.run` — this bug

This isolation strongly suggests the issue is specific to the `run`
action's request-construction code path, not the broader MCP tool's auth,
transport, or generic request handling.

Steps to Reproduce

Reproduction Steps

Three invocations were attempted. Trigger IDs and request IDs are real and
captured verbatim from the session.

Attempt 1 — trigger_id at top level, no body

Invocation:

RemoteTrigger(action="run", trigger_id="trig_01SqtbGaT8uZqFSjiTdYpVsZ")

Response:

HTTP 400
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "trigger_id: Extra inputs are not permitted"
  },
  "request_id": "req_011CaYPxFGV8RcKHmPBidumT"
}

Attempt 2 — trigger_id at top level + empty body

Invocation:

RemoteTrigger(action="run", trigger_id="trig_01SqtbGaT8uZqFSjiTdYpVsZ", body={})

Response:

HTTP 400
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "trigger_id: Extra inputs are not permitted"
  },
  "request_id": "req_011CaYPxhcjzkyf8GPLk7op8"
}

Attempt 3 — trigger_id placed only inside body

Invocation:

RemoteTrigger(action="run", body={"trigger_id": "trig_01SqtbGaT8uZqFSjiTdYpVsZ"})

Response (local tool validator, never reached the API):

<error>run requires trigger_id</error>

Expected vs Actual

Expected: RemoteTrigger.run with a valid trigger_id should fire the
specified trigger immediately (manual ad-hoc invocation), returning HTTP 200
with the new run's metadata.

Actual: Every invocation returns HTTP 400 with the body-validation
rejection (Attempts 1 & 2), or is rejected by the local validator before
ever reaching the API (Attempt 3).

Root Cause Analysis

The MCP tool's request construction places trigger_id in the JSON request
body. The Anthropic CCR API for POST /v1/code/triggers/{trigger_id}/run
expects:

• trigger_id in the URL path (path parameter)
• The request body to contain ONLY run-time parameters (e.g. overrides), or

to be empty {}

When the tool sends {"trigger_id": "trig_..."} in the body, the API's
strict validator (likely pydantic-based, given the error message format)
rejects trigger_id as an unknown extra field.

This is consistent with the action's documented contract:

run: POST /v1/code/triggers/{trigger_id}/run (optional body)

— which describes the path-parameter form. The bug is a translation mistake
in the tool's request-construction code path: trigger_id is being passed
through to the body instead of substituted into the URL.

Confirming the issue is tool-side, not auth/contract:

• RemoteTrigger.create, RemoteTrigger.update, RemoteTrigger.get,

RemoteTrigger.list all work correctly via the same MCP tool surface
with the same auth context. Verified today by:

• update against two existing triggers — HTTP 200, payloads returned

with all expected fields preserved and modified sources list
reflected

• get and list returning full trigger configs (HTTP 200) before and

after the update calls

• The run action is uniquely affected
• No workaround within the MCP tool surface — the local validator forbids

omitting trigger_id, so a request with body-only trigger_id cannot be
constructed

• No curl-around possible — per the MCP tool design, the OAuth bearer is

in-process and not exposed to the consumer

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_