Getting this error at a high rate for longer running agent runs, specifically for Claude models.
Hi @David_Bressler
I’ve seen this error before when the model returns tool input that doesn’t match the expected JSON schema. To help narrow it down, could you share one example of the tool input produced when the error happens? Understanding how your workflow is structured is also essential to help diagnose it, so seeing the actual payload and a bit of context about the workflow would make it much easier to identify whether it’s a schema mismatch or something related to longer agent runs.
[
{
“sandbox_id”: “ifxdlb1gnbi24vhvl5y5y”,
“status”: “success”,
“message”: “S3 folder ‘7ce7b1a6-bb87-4cba-aeda-2042a886ff0a/37ee94a1-e775-40a5-ae68-796260188a92’ mounted”,
“mount_path”: “/home/user/workspace”,
“s3_path”: “s3://excel-formulabot-rds-storage/7ce7b1a6-bb87-4cba-aeda-2042a886ff0a/37ee94a1-e775-40a5-ae68-796260188a92”,
“files”: [
{
“name”: “1772725712416_Active-Campaigns-Current-Quarter__1_.xlsx”
},
{
“name”: “outputs”
}
],
“file_count”: 2,
“error”: “Received tool input did not match expected schema\n\n✖ Required\n → at code”
}
]
What seems to be happening is that the agent is trying to call a tool but the generated input isn’t matching what the schema expects. In this case the error is saying the required “code” field is missing. The model most likely produced a malformed tool call during a longer run.
Longer Claude agent runs tend to show this more often because the model is generating tool calls and drifts occasionally from the required schema. N8n is still initializing the sandbox when this happens(which uus why the S3 mount succeeds) but the execution fails once the tool input is validated.
The best practice to mitigate this is by tightening the tool schema and adding clearer tool descriptions as well as validation/retry logic so the malformed tool calls get regenerated.
Looking at the error payload you shared — the tool response itself contains the error message, which is the key thing here.
The issue: your Code node is returning a response object that includes an error key with the schema validation message baked in as a string — rather than throwing a proper error or returning a clean result.
What’s happening: Claude received a tool result that looked valid on the surface (the outer call succeeded), but it had that malformed error string embedded inside. Then on the next tool call, Claude tried to pass inputs based on that response, which triggered the downstream schema validation failure.
Things to check:
1. Code node output schema mismatch — if you have Output set to a specific schema in your Code node, verify the fields you’re returning exactly match what’s defined. The → at code part of the error usually means the Code node’s output definition doesn’t match what it’s actually returning.
2. Required fields — ✖ Required means a field marked as required in the tool schema is missing from the output. Check your Code node’s Define Output section and make sure every required field is always present — use a fallback/default if a value could ever be missing.
3. Context window pressure on longer runs — since you said it happens more on longer agent runs, this could be the model dropping required tool inputs due to context window pressure. Adding a System Prompt instruction like always provide all required fields in every tool call can help mitigate this.
Quick fix: Wrap your Code node output in a try/catch and always return a full object with defaults for every required field, even if some values are null. That way the schema validator never hits a missing key.
Share your Code node’s output definition if you want eyes on the specific mismatch!
Will updating from execute sub workflow to an HTTP request as the tool call fix this?
Hi @David_Bressler!
I don’t think switching to HTTP Request would fix this one.
What usually helps is simplifying the tool schema and making sure the tool description clearly tells the model to always include the required fields. Also, double-check that your Code node output always returns all fields defined in the schema (even if some are null or empty).