[LukasParke]

TL;DR

Review findings on the #170 vendoring in openrouter-web #55480: Deep SWE and SWE Atlas dropped provider pins for the sandboxed CLI, the pi extension dropped the agent's own plugins, the Responses client refused redirects on every request, the sandbox target guard rejected the bare https://openrouter.ai origin, and pluginId was exported without a caller.

What changed?

• deep-swe/benchmark.ts, swe-atlas/benchmark.ts: agentCli options now carry providerOnly and allowFallbacks (Terminal Bench already did), so the pi extension pins provider.only / allow_fallbacks inside the sandbox.
• agent-cli/harness.ts: the pi extension merges extraBody.plugins with the plugins already on the agent payload by id (configured wins on a shared id) before applying the generated router plugins, instead of spread-replacing the array.
• providers/responses-client.ts: redirect: "error" is set only when the request carries cf-access-* headers; other requests keep Fetch's default follow, matching the shared HTTP client.
• agent-cli/sandbox-target.ts: the normalized endpoint appends /api/v1 when the path does not already end with it (as normalizeBaseUrl in the responses client does), and a URL with a query or fragment is rejected. https://openrouter.ai and https://openrouter.ai/ pass; /preview/api/v1, /api/v2, ?mode=test, #frag, malformed URLs and api-perf Previews are rejected.
• providers/router-plugin.ts: pluginId is module-local.

Why?

Perry review threads 4428045639, 4428045672, 4428045677 and Devin Review findings on #55480: a pinned Deep SWE / SWE Atlas pi trial could run on another provider without an error, a payload web plugin was lost when extraBody.plugins was configured, a custom base URL that redirects to its canonical endpoint failed every request, and a Kepler-allowlisted bare origin was rejected for sandboxed agents.

How to test

bun run format:check && bun run check && bun run typecheck && bun test && bun run build

Expected: all green. New/updated tests: agent-cli/sandbox-target.test.ts (origin-only accepted; query/fragment/alternate path rejected), agent-cli/harness.test.ts (payload plugins merged with configured plugins; override keeps the payload's own plugins), providers/responses-client.test.ts (redirect refusal only with Access headers).

Reviewer focus

• Plugin precedence in the pi extension: payload plugins < extraBody.plugins < generated router plugins, with a configured same-id plugin overriding the generated one.
• redirectPolicy reads the final request headers, so Access headers added through traceHeaders are what toggle the refusal.

Checklist

• Tests cover changed behavior
• Public API or configuration changes are backward compatible, or the break is documented (pluginId had no external callers)
• Benchmark changes document dataset provenance and licensing (n/a)
• No credentials, private results, or restricted dataset contents are included
• Documentation is updated where needed (n/a)

Link to Devin session: https://openrouter.devinenterprise.com/sessions/1f0ee04b0a0846499f37c98842c75206
Open in Devin Desktop: https://openrouter.devinenterprise.com/desktop/session/1f0ee04b0a0846499f37c98842c75206?variant=devin
Requested by: @LukasParke

---

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'Devin'.

• Disable automatic comment, CI, and merge conflict monitoring

---

Original prompt from Luke

SYSTEM:
<latest_message>
Luke Parke (U0BF2BKT52N) [ts=1793201601.638509]: @Devin in a new session, take over the core effort in this thread

First things first we need to fix the issues causing router failures during the matrix testing
</latest_message>

=== BEGIN THREAD HISTORY (in #agents) ===
Luke Parke (U0BF2BKT52N) [ts=1793201601.638509]: @Devin in a new session, take over the core effort in this thread

First things first we need to fix the issues causing router failures during the matrix testing
=== END THREAD HISTORY ===
Channel ID: C07UF9XLTFF
Thread URL: https://openrouter.slack.com/archives/C07UF9XLTFF/p1793201601638509?thread_ts=1793201601.638509&amp;cid=C07UF9XLTFF

The <latest_message> is the message that you should use to guide your goals + task for this session, and you should use the rest of the slack thread as context.
A [ts=...] marker on a Slack message is that message's timestamp. To act on a specific message with the slack tool (e.g. adding an emoji reaction via the reaction command), pass that value as timestamp along with the Channel ID — no extra lookup call is needed.