Gemini 3.1 Pro: malformed tool_use blocks cause 'command is required and must be a string' in Factory CLI

[anand-92]

Summary

When using Gemini 3.1 Pro (gemini-3.1-pro-preview) through DroidProxy, the Factory CLI (droid) rejects tool calls with:

Execute
    ↳ Error: command is required and must be a string

Claude (Opus 4.7) and other providers work fine from the same session — the issue is specific to Gemini's tool_use output.

Environment

• DroidProxy v1.8.8 (macOS app bundle at ~/Applications/DroidProxy.app)
• CLIProxyAPIPlus v6.9.28-0-plus running on 127.0.0.1:8318
• ThinkingProxy on localhost:8317
• Factory CLI (droid) as client
• Model: gemini-3.1-pro-preview with thinking_level=high
• macOS (darwin 25.4.0)

Reproduction

1. Configure DroidProxy with Gemini 3.1 Pro at thinking level "high"
2. Send a request from Factory CLI that should invoke the Execute tool
3. Observe the CLI error: Execute → Error: command is required and must be a string

Observations from /tmp/droidproxy-debug.log

Proxy-side everything looks correct:

[2026-04-21T13:57:05Z] INCOMING REQUEST: POST /v1/messages
[2026-04-21T13:57:05Z] ORIGINAL BODY (first 500): {"model":"gemini-3.1-pro-preview","max_tokens":65536,...}
[2026-04-21T13:57:05Z] INJECTED Gemini thinking: level=high for model gemini-3.1-pro-preview
[2026-04-21T13:57:05Z] MODIFIED BODY (first 500): {"model":"gemini-3.1-pro-preview","generationConfig":{"thinkingConfig":{"thinking_level":"high"}},...}
[2026-04-21T13:57:05Z] THINKING INJECTED: true

• Request is well-formed
• generationConfig.thinkingConfig.thinking_level=high injected by ThinkingProxy.swift
• No upstream HTTP errors logged (~/.cli-proxy-api/logs/ has no error files newer than Apr 18)
• Both proxy ports (:8317, :8318) are live and healthy

The error is emitted by the Factory CLI when it parses a tool_use block whose input is missing the command field (or contains an empty/non-string value). This suggests Gemini is returning a function-call chunk that cli-proxy-api-plus translates into a tool_use with incomplete args.

Likely cause

One of:

1. Gemini's SSE stream emits a partial functionCall chunk that the v1/messages translator forwards as a tool_use before the args are complete.
2. Gemini hallucinates a call to Execute without populating the required command arg.
3. The Gemini-to-Anthropic translation in cli-proxy-api-plus drops the arg when generationConfig.thinkingConfig.thinking_level=high changes the response shape (e.g., reasoning tokens interleaved with the tool call).

Next steps

• Add response-body logging to ThinkingProxy (or tap cli-proxy-api-plus output) to capture the raw Gemini reply that produces the bad tool_use block
• Try thinking_level=medium / low to check if the issue is triggered specifically by high reasoning
• Check whether cli-proxy-api-plus needs an update that better handles interleaved reasoning + function-call chunks for Gemini 3.1
• Consider emitting the tool_use block only after the full functionCall args JSON has been received

Workaround

Switch to Claude (Opus 4.7) or another provider. Gemini is effectively unusable for tool-driven sessions until the malformed tool_use is fixed.

[anand-92]

Updated findings

Ruled out:

• Auth / token refresh — Gemini auth file (~/.cli-proxy-api/nik.anand.1998@gmail.com-reefkits-reefki.json) is healthy, disabled: false, token present. A direct /v1/messages call to 127.0.0.1:8318 with gemini-3.1-pro-preview returns the full assistant message including thinking blocks:

  {"type":"text","text":"pong"}
  {"type":"thinking","thinking":"..."}
  

• Proxy / thinking injection — ThinkingProxy is cleanly injecting generationConfig.thinkingConfig.thinking_level=high and forwarding. No recent code changes to the Gemini path.

Observed narrower scope:

• Text + thinking stream through fine.
• Only tool_use blocks are broken. File creation (and any tool invocation) fails 100% of the time with Execute → Error: command is required and must be a string in the Factory CLI.
• Droid's built-in Gemini 3.1 Pro (not going through DroidProxy) creates files successfully, so the issue is isolated to the DroidProxy → CLIProxyAPIPlus → Gemini pipeline, not Gemini itself.
• Was working until today. No DroidProxy code changes in the last several days (last Gemini-path change was bac02ff fix: Gemini native provider routing, thinking injection...). Suggests upstream drift:
  • Either Gemini's functionCall chunk format changed, or
  • cli-proxy-api-plus v6.9.28-0-plus has a bug translating Gemini function calls into Anthropic tool_use blocks that surfaces only for certain tool schemas (e.g., Factory CLI's Execute with a required command string arg), or
  • Factory CLI's tool schema / validation tightened in a recent release and now rejects the empty-input tool_use block cli-proxy-api-plus was already producing.

Next steps

• Capture the raw Gemini response body for a failing tool call (add response logging to ThinkingProxy or run cli-proxy-api-plus manually with verbose logging).
• Check cli-proxy-api-plus upstream for any Gemini tool_use translation fixes since v6.9.28-0-plus.
• Compare the streamed tool_use JSON emitted via DroidProxy vs via Droid's built-in Gemini to see exactly which field is empty/missing.

[anand-92]

Actual root cause found — factory-cli 0.105.1 bug

Not a DroidProxy or CLIProxyAPIPlus bug. Today's factory-cli update (from droid.bak dated 2026-03-05 to droid dated 2026-04-21 09:49 EDT, version factory-cli/0.105.1) double-prefixes the path for custom Gemini models.

Evidence

~/.cli-proxy-api/logs/ captured four 404s during the failing session, all within 12 seconds:

error-v1-v1-messages-2026-04-21T103531-2.log
error-v1-v1-messages-2026-04-21T103533-4.log
error-v1-v1-messages-2026-04-21T103537-6.log
error-v1-v1-messages-2026-04-21T103543-8.log

URL:        /v1/v1/messages    ← doubled /v1
Method:     POST
User-Agent: factory-cli/0.105.1
Status:     404
model:      gemini-3-flash-preview
messages:   1 (first turn, no tool history)

ThinkingProxy log confirms the same:

[2026-04-21T14:35:31Z] INCOMING REQUEST: POST /v1/v1/messages
[2026-04-21T14:35:33Z] INCOMING REQUEST: POST /v1/v1/messages
[2026-04-21T14:35:37Z] INCOMING REQUEST: POST /v1/v1/messages
[2026-04-21T14:35:43Z] INCOMING REQUEST: POST /v1/v1/messages
[2026-04-21T14:35:59Z] INCOMING REQUEST: POST /v1/messages   ← fallback after 4x 404

What factory-cli is doing wrong

With the custom-model setting:

{
  "model": "gemini-3-flash-preview",
  "baseUrl": "http://localhost:8317",
  "provider": "anthropic"
}

factory-cli 0.105.1 auto-prepends /v1 to baseUrl only when the model name starts with gemini-, then its Anthropic-SDK-based client still appends /v1/messages, producing http://localhost:8317/v1/v1/messages.

• Claude/Sonnet custom models with the same baseUrl and provider: anthropic hit /v1/messages correctly (grepped entire log — zero /v1/v1 hits for claude-*)
• Only gemini-* + provider: anthropic reproduces the doubled path

After 4 failed retries at /v1/v1/messages, factory-cli's fallback path drops the extra /v1 and subsequent requests in the same session go to /v1/messages and succeed. That matches the observed pattern:

• First tool call in a fresh session fails 4x then bails
• Warm tool calls (after a prior successful request) succeed
• Flash fails more often than Pro because Pro holds the session warm longer per request

Proposed workaround in DroidProxy

Patch ThinkingProxy.swift to rewrite /v1/v1/... → /v1/... before forwarding to CLIProxyAPIPlus. This hides the factory-cli bug entirely and restores first-turn tool calls for Gemini models on provider: anthropic.

Minimal change near processRequest (around line 258):

// Strip doubled /v1 prefix that factory-cli 0.105.1 emits for custom
// Gemini models under provider=anthropic.
if path.hasPrefix("/v1/v1/") {
    rewrittenPath = String(path.dropFirst(3)) // /v1/v1/messages -> /v1/messages
    NSLog("[ThinkingProxy] Rewriting doubled /v1 prefix: \(path) -> \(rewrittenPath)")
    ThinkingProxy.fileLog("REWRITE PATH: \(path) -> \(rewrittenPath) (factory-cli /v1/v1 workaround)")
}

Ruled out during investigation

• CLIProxyAPIPlus v6.9.28-0-plus (current) vs v6.9.31 mainline — no Gemini tool_use translator fixes between them
• Gemini auth / token refresh — token is healthy, pong test returned full thinking + text
• tool_use id prefix difference (call_ vs toolu_) — red herring; accepted by other Anthropic-compatible clients
• Schema validation — curl tests with Create/Edit/Execute tool schemas all return valid tool_use blocks with proper input JSON

Why the auto-update workflow didn't help

.github/workflows/update-cliproxyapi.yml polls router-for-me/CLIProxyAPIPlus, whose latest tag is still v6.9.28-0 (same as bundled). The mainline CLIProxyAPI is at v6.9.31 but the Plus fork hasn't caught up. The workflow is behaving correctly — there is simply nothing newer to pull on the Plus side, and even if there were, the fix has to live in factory-cli (or as a workaround in ThinkingProxy).

[anand-92]

Follow-up: second distinct bug confirmed (upstream factory-cli bug, not a proxy issue)

The /v1/v1/messages 404 from factory-cli 0.105.1 is now fixed on the proxy side via a gated path rewrite in ThinkingProxy.swift:

• Default-on toggle: AppPreferences.geminiV1PathFix
• UI: Settings → Gemini → "Fix factory-cli /v1/v1 path bug"
• Rewrite: /v1/v1/... → /v1/..., /api/v1/v1/... → /api/v1/...

All requests in /tmp/droidproxy-debug.log now hit /v1/messages and no new error-v1-v1-messages-*.log files are produced.

Remaining issue: factory-cli can't parse Gemini tool_use input JSON

Even with the path fix in place, Create/Edit/Read calls still fail on gemini-3-flash-preview with Operation failed - check parameters and try again. ~/.factory/logs/droid-log-single.log shows:

WARN: Failed to parse tool input JSON
  toolName: "Read" (or "Create")
  error: SyntaxError: JSON Parse error: Unable to parse JSON string
    at OFD (src/hooks/createLLMStreamingCore.ts:171:23)

When this catch fires, factory-cli sets tool_use.input = {} and sends empty args to the tool, which is what produces the user-facing "Operation failed" message.

Verified: upstream returns valid JSON

Repro'd directly against the proxy with curl:

curl -sN -X POST http://localhost:8317/v1/messages \
  -H "Content-Type: application/json" -H "anthropic-version: 2023-06-01" \
  --data-binary @req.json

Response contains a single well-formed input_json_delta:

data: {"type":"content_block_delta","index":0,"delta":{"type":"input_json_delta",
       "partial_json":"{\"content\":\"\\u003c!DOCTYPE...\",\"file_path\":\"pokeball.html\"}"}}

The partial_json string is 3076 chars, parses cleanly with:

• Python json.loads() → OK
• Node JSON.parse() → OK (returns {content: '...', file_path: 'pokeball.html'})
• Direct hit against http://localhost:8318/v1/messages (bypassing ThinkingProxy) → same valid output

No control chars in strings, no raw \n/\t/\r, no encoding issues. The data is spec-compliant.

Conclusion

This is a factory-cli 0.105.1 bug in how createLLMStreamingCore.ts:171 accumulates and parses input_json_delta events for Gemini tool_use streams. It is not fixable from the proxy side because the data we're emitting is already valid JSON that every other parser accepts.

Likely needs to be reported to Factory directly. Temporary user workaround: use gemini-3.1-pro-preview instead of gemini-3-flash-preview (different streaming chunk size may avoid the parser bug, needs confirmation), or fall back to Claude models for tool-heavy tasks.

Files changed in this fix

• src/Sources/AppPreferences.swift — added geminiV1PathFix key, default true, getter
• src/Sources/ThinkingProxy.swift — path rewrite gated by AppPreferences.geminiV1PathFix
• src/Sources/SettingsView.swift — @AppStorage binding + toggle checkbox in Gemini Model Settings