devin: swe-2 rejects any tool declaration upstream (permission_denied: MCP configuration issue) while swe-1-7 accepts the same payload

[raphaelnz]

Environment

• CLIProxyAPI: HEAD-7bbfeaf (7.3.3+), macOS arm64, brew build
• Devin auth: OAuth login via -devin-login (session token, standard account)

Summary

Requests to devin/swe-2 that include ANY tool declaration fail deterministically upstream with permission_denied / "Unable to process request due to an MCP configuration issue". The exact same payload with model=devin/swe-1-7 succeeds, including real function calls.

Repro (via local proxy)

1. Works — swe-2, no tools:
   POST /v1/responses {"model":"devin/swe-2","input":"hi","max_output_tokens":2000} → 200

2. Fails — swe-2, one minimal function tool:
   POST /v1/responses {"model":"devin/swe-2","input":"weather in seoul? use the tool","tools":[{"type":"function","name":"get_weather","description":"Get weather","parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}]} → 503
   devin upstream error (permission_denied): Unable to process request due to an MCP configuration issue. (trace ID: 2c5cdda10de14e5edda1b671f1040d30)

3. Works — same payload with swe-1-7: → 200 with function_call get_weather({"city":"Seoul"})

Additional observations:

• Tool name style does not matter (get_weather, mcp__local__get_weather, shell all fail on swe-2).
• Reproduces on both /v1/responses and /v1/chat/completions.
• Separately, Devin upstream occasionally returns invalid_argument: an internal error occurred (e.g. trace ID e246907cc952746d2ad0bb5f7046d0a6) that is transient — retrying the identical payload succeeds. Full Codex-CLI-sized payloads (~40 tools incl. namespace/custom types) also hit intermittent stream drops (stream disconnected before completion) on swe-1-7.

Guess: swe-2 appears to gate externally-declared tools (MCP-style) on the account/backend side, or requires a different tool declaration encoding than field-10 repeated tools.

Happy to test any patch or capture more traces.

[luxi233]

+1

[luispater]

Thanks for the detailed repro.

The following request succeeds here, including with the same minimal get_weather tool on devin/swe-2:

curl -X POST http://127.0.0.1:8317/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer 12345" \
  -d '{"model":"devin/swe-2","input":"weather in seoul? use the tool","tools":[{"type":"function","name":"get_weather","description":"Get weather","parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}]}'

Because this payload works on our side, we need the complete request log from a failing run on your machine to see what actually went upstream (client payload, translated interactions, Devin wire body, and the trailer/error). The error line alone is not enough.

How to capture the request log

1. In config.yaml, set:

request-log: true

If commercial-mode: true is set, temporarily set it to false as well; commercial mode disables this high-overhead request logging.

2. Restart CLIProxyAPI, or wait for config hot-reload if the watcher is running.

3. Reproduce the failing devin/swe-2 request once (the original client call is preferred over a minimized curl if they differ).

4. Find the new file under the logs/ directory relative to the server process working directory. For this endpoint the name looks like:

v1-responses-<timestamp>.log

If you are unsure of the working directory (Homebrew/launchd/service installs often are not the repo root), search for the newest v1-responses-*.log.

5. Attach that full log file here. Please keep these sections intact:

• === REQUEST INFO ===
• === HEADERS ===
• === REQUEST BODY ===
• === API REQUEST === / === INTERMEDIATE INTERACTIONS === / === DEVIN UPSTREAM REQUEST ===
• === RESPONSE === / === DEVIN UPSTREAM RESPONSE ===

Redact secrets before uploading (Authorization, session tokens, cookies, account identifiers). Do not trim the tool list, model UID, or error trailer.

6. After capturing the log, you can set request-log: false again.

Without that complete request log we cannot tell whether your failing call differs from the curl above (extra tools, client wrapping, system prompt, headers, or a different upstream model UID).

[extirpate]

可能是sse的response 请求就会报错，终端改成openai兼容模式应该就可以了，终端如果用openai就会出错。
我在opencode中，@ai-sdk/openai 就会工具调用报错，改成@ai-sdk/openai-compatible就正常了。AI帮我查的原因是：
swe-2 的上游网关在流式输出工具调用时，把全局 Item 序号（如 2、3）错当成了工具序号（应该从 0 开始）；而 OpenCode 的 @ai-sdk/openai 驱动在流结束遍历工具数组时，因为遇到前面的空位（undefined），直接触发了 JavaScript 的 TypeError 崩溃，导致工具流被硬切断，最终被 OpenCode 兜底标记为 Tool execution aborted。

一、根本原因深度解剖（全链路证据）

1. 上游返回的 SSE 帧序号偏斜（index: 2）
   我们用相同的请求对 https://api.swiflly.com/v1/chat/completions 发起流式测试（stream: true），截获了它发出的真实 SSE 数据帧：
   // 帧 1：思考过程（Item 0）
   data: {"choices":[{"delta":{"reasoning_content":"The user wants to test..."}}]}

// 帧 2：文本正文（Item 1）
data: {"choices":[{"delta":{"content":"我检测到 evaluation/试用意图..."}}]}

// 帧 3：发起工具调用（Item 2）
data: {"choices":[{"delta":{"tool_calls":[{"index":2,"id":"read:0#...","type":"function","function":{"name":"read","arguments":""}}]}}]}

// 帧 4：工具调用参数填充
data: {"choices":[{"delta":{"tool_calls":[{"index":2,"function":{"arguments":"{"filePath":"..."}"}}]}}]}
在 OpenAI 官方规范 中，choice.delta.tool_calls 内部的 index 必须是该消息中工具调用的自身序号，必须从 0 开始递增（0, 1, 2...）。
但 swe-2 上游是将内部 Responses 协议（Item 0: reasoning, Item 1: message, Item 2: function_call）机械翻译为 Chat Completion SSE 帧，导致第一个工具调用的 index 变成了 2（如果有多个则是 2, 3, 4）。
2. OpenCode 内置 @ai-sdk/openai 解析器致命崩溃
在 OpenCode 的运行时二进制中，@ai-sdk/openai 接收到 index: 2 时，会把工具对象放入数组：
// OpenCode 内部处理 SSE 帧
toolCalls[toolCallDelta.index] = { ... };
// 此时 toolCalls 数组变成了稀疏数组：[undefined, undefined, toolCall]
当该轮模型输出完毕、执行流的 flush() 钩子时：
flush(H) {
// 注意这里的 for...of 遍历！
for (let h of toolCalls) {
if (!h.hasFinished) { // <-- 致命 Bug！
H.enqueue({ type: "tool-call", ... });
}
}
}
致命 Bug 点：
JavaScript 的 for...of 会遍历数组中的所有空洞项（hole）。当遍历第 0 项时，h 是 undefined。
执行 !h.hasFinished 时立即抛出未捕获异常：
TypeError: Cannot read properties of undefined (reading 'hasFinished')
3. OpenCode 收到流异常，触发中止保护

1. 因为异常抛出，流在派发 type: "tool-call" 事件之前就被掐断了；
2. OpenCode 的 SessionProcessor 捕获到流异常，查看本地消息中的工具状态：发现 read 和 bash 刚创建完（处于 pending 状态，参数为空 {}），模型流就已经终止；
3. OpenCode 触发安全清理逻辑：
   for (const part of parts) {
   if (part.type === "tool" && part.state.status !== "completed" && part.state.status !== "error") {
   await Session.updatePart({
   ...part,
   state: { status: "error", error: "Tool execution aborted" }
   });
   }
   }
4. OpenCode 日志中打印警告（我们在你的日志中找到了这条记录）：
   WARN message="loop exit with orphaned interrupted tool" tool=read callID=read:0#...
5. 界面上就渲染出了截图中的：Read / bash 参数为空，并标红显示 Tool execution aborted。

[Haven2026]

Narrowing this down on v7.3.9 (commit 61fdfc3): it is not the presence of tool declarations — it is the tool description content.

A/B tests against devin/swe-2 through CPA v7.3.9, same endpoint, same credential:

Request shape	Result
No tools, neutral system prompt	200
Raw Claude Code system prompt, no tools	200 — cliproxy already sanitizes it via SanitizeDevinSystemPrompt + the devin.sensitive-words matcher
34 function tools, original descriptions	403 permission_denied: "Unable to process request due to an MCP configuration issue"
Same 34 tools, every description truncated to ≤480 chars	200
Same 34 tools, description removed entirely	200

So the "MCP configuration issue" message is misleading — Devin upstream runs a pre-inference content filter over tool descriptions. The descriptions that trip it sit in the long tail: text about credentials/secrets, cross-session messaging, permission modes, shell command execution (this was a Claude Code 2.1.278 toolset — SendFeedback, SendMessage, Monitor, Bash, etc.). Everything under ~480 chars passed; all the suspect content lived past that point.

Code path: internal/runtime/executor/helps/devin_wire.go runs SanitizeDevinSystemPrompt(systemPrompt, matcher) on the system prompt (why raw CC prompts pass), but tool descriptions only go through translatorcommon.SanitizeDevinToolDescription — two hard-coded phrase substitutions for exec_command/write_stdin plus task_id→taskId normalization. The configured devin.sensitive-words matcher never touches tool descriptions.

Patch we are now running in production (on top of tag v7.3.9):

+	// devinToolDescriptionMaxLen caps tool description length (in runes); Devin
+	// upstream rejects requests whose tool descriptions exceed this limit.
+	devinToolDescriptionMaxLen = 480

 		desc = translatorcommon.SanitizeDevinToolDescription(tool.Name, desc)
+		if r := []rune(desc); len(r) > devinToolDescriptionMaxLen {
+			desc = string(r[:devinToolDescriptionMaxLen])
+		}
 		if desc != "" {
 			tBytes = protowire.AppendTag(tBytes, 2, protowire.BytesType)
 			tBytes = protowire.AppendString(tBytes, desc)
 		}

Verified: the same 34-tool request that 403'd now returns 200. Rune-wise truncation avoids splitting multi-byte UTF-8 (proto string fields require valid UTF-8; protowire.AppendString does not validate).

Caveat: 480 is an empirically derived cap, not a known upstream threshold. Alternative shapes if you prefer:

• route tool descriptions through the same devin.sensitive-words matcher as the system prompt (semantic obfuscation rather than truncation — only helps if the trigger is specific words rather than overall length/semantics)
• make the cap configurable (e.g. devin.tool-description-max-len) since the upstream threshold may move

Happy to open a PR with whichever shape you prefer.

[Haven2026]

Follow-up: after a review pass on the patch I posted above, we refined it — the cap is now byte-based, cut at a rune boundary (the first version capped runes; if the upstream limit is byte-measured, multibyte text could still exceed it). Deployed and verified in production:

+	// devinToolDescriptionMaxLen caps tool description length in bytes; Devin
+	// upstream rejects requests whose tool descriptions exceed this limit.
+	devinToolDescriptionMaxLen = 480

 		desc = translatorcommon.SanitizeDevinToolDescription(tool.Name, desc)
+		if len(desc) > devinToolDescriptionMaxLen {
+			cut := devinToolDescriptionMaxLen
+			for cut > 0 && !utf8.ValidString(desc[:cut]) {
+				cut--
+			}
+			desc = desc[:cut]
+		}
 		if desc != "" {

(The same truncation is also mirrored into BuildDevinUpstreamLogBody so the debug log shows what actually goes on the wire. unicode/utf8 is already imported in that file.)

Verified on devin/swe-2: 660-byte ASCII description → 200; 304 CJK chars ≈912 bytes (would have slipped under a rune cap) → 200.

Honest residual risk, worth flagging for whichever fix shape lands: the patch covers proto field 2 (tool description) only. Field 3 — tool.Parameters, the raw JSON schema — still travels verbatim, and nested schema description keys are neither sanitized nor truncated. Our A/B only proves field 2 was implicated for the tested 34-tool Claude Code payload (full schemas passed unchanged). If 403s resurface on a different toolset, schema parameters is the first place to look — a belt-and-suspenders version would normalize/truncate nested "description" values inside the schema too (cf. NormalizeCodexToolSchemas, which exists but is only wired into Codex executors, not the Devin path).

Also for completeness: SanitizeDevinToolDescription only obfuscates two hard-coded phrases for exec_command/write_stdin-suffixed tools (internal/translator/common/devin_tools.go:63-68). A differently-named tool carrying the same phrase, or any other upstream-flagged content in a sub-480 description, still goes through untouched — the truncation is a heuristic cap, not a guarantee. The configurable/matcher-based alternatives from my first comment stand.