Unwrap lingua-mangled tool-call arguments before dispatch

[akrentsel]

Symptom

After rebuilding exo for the first time since June 8, every agent turn that calls a tool (e.g. shell) fails with execute_tool failed: missing field \command`` and the model retries the identical call forever — a token-burning infinite loop.

Cause

The lingua/braintrust model router bumped in #69 (June 16, rev 3ab9bcc9) serializes tool-call arguments through its internal serde representation, leaking two shapes into the function_call arguments JSON:

1. A Result envelope wrapping the real args as a string: {"type":"valid","value":"{\"command\":\"ls\"}"}
2. serde_json::Value numbers as a tagged object: {"$serde_json::private::Number":"3000"}

Either shape makes the real arguments unreachable — the tool sees no command/url/etc. field, errors, and the model loops. This had been latent in the tree since June 16; it only surfaced when a fresh build finally ran the newer router.

Fix

unwrapLinguaToolArguments in responseToolCallResults recursively undoes both shapes before dispatch, so tools receive the arguments the model actually produced. Anything not matching these shapes passes through unchanged. Model-agnostic and applies to every tool and harness.

Tests cover the two exact corrupt payloads captured from a live loop (shell envelope, web_fetch with a nested serde number) plus a well-formed-arguments passthrough.

Root cause is upstream in lingua (a vendored git dep); this is the pragmatic guard at the TS boundary. Reverting to the pre-#69 rev 10f863cf is the alternative but risks whatever #69 needed.

🤖 Generated with Claude Code

[ankrgyl]

Thanks for tracking this down. I think the durable fix should be at the Rust/Lingua boundary rather than as a recursive TS unwrap.

There are two separate leaks here:

1. $serde_json::private::Number happens when lingua::serde_json::Value / arbitrary-precision serde JSON is exposed through a generic serializer. The pattern we use in Braintrust is to serialize at the edge with lingua::serde_json::to_string(...) and then parse into the target representation (JSON.parse in wasm, or normal serde_json::from_str in Rust). In other words, avoid handing a lingua::serde_json::Value directly to serde_wasm_bindgen / generic to_value at a JS/plain-JSON boundary.

2. { "type": "valid", "value": ... } is different: that is the tagged serde representation of Lingua ToolCallArguments enum leaking. The OpenAI Responses function_call.arguments field should not serialize the enum directly. It should match the enum and emit only the provider-expected payload:

match args {
    ToolCallArguments::Valid(map) => lingua::serde_json::to_string(map)?,
    ToolCallArguments::Invalid(raw) => raw.clone(),
}

If the target field wants a JSON value rather than a string, use Value::Object(map.clone()) for valid args and Value::String(raw.clone()) for invalid args.

So I think this TS shim is a useful guard, but the upstream Rust fix should be: unwrap ToolCallArguments before constructing OpenAI Responses function_call.arguments, and cross the Lingua arbitrary-precision JSON boundary via JSON text/bytes or Lingua custom wasm serializer.

[ankrgyl]

Thanks for tracking this down. I think the durable fix should be at the Rust/Lingua boundary rather than as a recursive TS unwrap.

There are two separate leaks here:

1. $serde_json::private::Number happens when lingua::serde_json::Value / arbitrary-precision serde JSON is exposed through a generic serializer. The pattern we use in Braintrust is to serialize at the edge with lingua::serde_json::to_string(...) and then parse into the target representation (JSON.parse in wasm, or normal serde_json::from_str in Rust). In other words, avoid handing a lingua::serde_json::Value directly to serde_wasm_bindgen / generic to_value at a JS/plain-JSON boundary.
2. { "type": "valid", "value": ... } is different: that is the tagged serde representation of Lingua ToolCallArguments enum leaking. The OpenAI Responses function_call.arguments field should not serialize the enum directly. It should match the enum and emit only the provider-expected payload:

match args {
    ToolCallArguments::Valid(map) => lingua::serde_json::to_string(map)?,
    ToolCallArguments::Invalid(raw) => raw.clone(),
}

If the target field wants a JSON value rather than a string, use Value::Object(map.clone()) for valid args and Value::String(raw.clone()) for invalid args.

So I think this TS shim is a useful guard, but the upstream Rust fix should be: unwrap ToolCallArguments before constructing OpenAI Responses function_call.arguments, and cross the Lingua arbitrary-precision JSON boundary via JSON text/bytes or Lingua custom wasm serializer.

(FYI Codex wrote this for me)

[Alexsun1one]

nice fix. one gap on the chat-completions side: assistantToolCalls (responses.ts:1068) re-serializes part.arguments straight back into the tool_calls history, so a model that emitted the {"type":"valid","value":...} envelope keeps seeing it in its own replayed history and keeps emitting it. i hit this driving fork with a deepseek model via --base-url: slug/purpose went through the tool call but the handler read undefined, and children fell back to fork-parent-fork-00N / purpose:null.

unwrapping in the history converter too closes the loop:

// assistantToolCalls, before serializing part.arguments:
const unwrappedArguments = unwrapLinguaToolArguments(part.arguments);
// ...JSON.stringify(isRecord(unwrappedArguments) ? unwrappedArguments : {})

one catch: here the envelope's value arrives already as an object (it came from stored history, not a raw JSON string), so unwrapLinguaToolArguments also needs to handle value being an object/array, not just a string.

happy to send this as a small PR onto this branch if useful.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	exo	c99f7eb	Jul 08 2026, 06:38 AM