Timeout compatibility issues when calling tools.

• Ran bash -lc 'ls','timeout_ms':600000
  └ bash: 行 1: ls,timeout_ms:600000: 未找到命令

Seeing the same thing here – I think the root cause is how the model formats the shell_command tool call after timeout_ms was added.

Codex expects function_call.arguments to be a JSON string that deserializes into something like:

{\"command\":\"bash -lc '…'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000}

But with gpt-5.1 it sometimes “leaks” fields like timeout_ms / workdir into the command string itself, so the shell ends up seeing:

bash -lc '…','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'}

and that’s exactly the zsh: parse error near '}' you’re hitting.

One thing that helped me was adding a small instruction to my agent prompt, just for shell_command:

### shell_command tool call (Codex)

When the model calls `shell_command`, it must set `function_call.arguments` to a JSON object encoded as a string, for example:

{\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000}

Rules:
- `command` must contain only the shell command; never embed `timeout_ms`, `workdir`, `{` or `}` or any other JSON fragments inside `command`.
- Put `workdir`, `timeout_ms`, `login`, `with_escalated_permissions`, and `justification` as separate top‑level JSON fields.
- Make sure the `arguments` string is valid JSON that `JSON.parse(...)` would accept.

Correct:
{\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000}

Incorrect (this is what causes `zsh: parse error near '}'`):
{\"command\":\"bash -lc 'jq \\\"...\\\" challs.json','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'}\"}

FWIW, I’ve noticed gpt-5.1-codex-max almost never does this, while plain gpt-5.1 does it more often. Would be nice if the Codex CLI could inject a stricter built‑in instruction like the snippet above automatically when you’re using non‑Codex models.

Seeing the same thing here – I think the root cause is how the model formats the shell_command tool call after timeout_ms was added. Codex expects function_call.arguments to be a JSON string that deserializes into something like: `` {\"command\":\"bash -lc '…'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} ` But with gpt-5.1 it sometimes “leaks” fields like timeout_ms / workdir into the command string itself, so the shell ends up seeing: ` bash -lc '…','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'} ` and that’s exactly the zsh: parse error near '}' you’re hitting. One thing that helped me was adding a small instruction to my agent prompt, just for shell_command: `markdown ### shell_command tool call (Codex) When the model calls shell_command, it must set function_call.arguments to a JSON object encoded as a string, for example: {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} Rules: - command must contain only the shell command; never embed timeout_ms, workdir, { or } or any other JSON fragments inside command. - Put workdir, timeout_ms, login, with_escalated_permissions, and justification as separate top‑level JSON fields. - Make sure the arguments string is valid JSON that JSON.parse(...) would accept. Correct: {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} Incorrect (this is what causes zsh: parse error near '}'): {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'}\"} ` FWIW, I’ve noticed gpt-5.1-codex-max almost never does this, while plain gpt-5.1` does it more often. Would be nice if the Codex CLI could inject a stricter built‑in instruction like the snippet above automatically when you’re using non‑Codex models.

I'll finish this part.

Seeing the same thing here – I think the root cause is how the model formats the shell_command tool call after timeout_ms was added. Codex expects function_call.arguments to be a JSON string that deserializes into something like: `` {\"command\":\"bash -lc '…'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} ` But with gpt-5.1 it sometimes “leaks” fields like timeout_ms / workdir into the command string itself, so the shell ends up seeing: ` bash -lc '…','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'} ` and that’s exactly the zsh: parse error near '}' you’re hitting. One thing that helped me was adding a small instruction to my agent prompt, just for shell_command: `markdown ### shell_command tool call (Codex) When the model calls shell_command, it must set function_call.arguments to a JSON object encoded as a string, for example: {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} Rules: - command must contain only the shell command; never embed timeout_ms, workdir, { or } or any other JSON fragments inside command. - Put workdir, timeout_ms, login, with_escalated_permissions, and justification as separate top‑level JSON fields. - Make sure the arguments string is valid JSON that JSON.parse(...) would accept. Correct: {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json'\",\"workdir\":\"/Users/test/my/subgroup\",\"timeout_ms\":600000} Incorrect (this is what causes zsh: parse error near '}'): {\"command\":\"bash -lc 'jq \\\"...\\\" challs.json','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'}\"} ` FWIW, I’ve noticed gpt-5.1-codex-max almost never does this, while plain gpt-5.1` does it more often. Would be nice if the Codex CLI could inject a stricter built‑in instruction like the snippet above automatically when you’re using non‑Codex models.

I found this part of the problem, but I don't know if it is reasonable to change the prompt+ to process the output of llm, (do you need the consent of the contributor?

Helpful context about gpt-5.1 vs. gpt-5.1-codex-max, thank you!

Helpful context about gpt-5.1 vs. gpt-5.1-codex-max, thank you!

Can I be assigned to implement it? For a model that has already been released, updating the same version number is relatively low, so modifying the parsing implementation of Codex might be better. @dylan-hurd-oai

There may be a new development regarding this issue; the root cause might be that Codex tends to use bash -lc, leading to command wrapping. The following prompt would be more concise and effective:

Hard Requirement: call binaries directly in functions.shell, always set workdir, and avoid shell wrappers such as `bash -lc`, `sh -lc`, `zsh -lc`, `cmd /c`, `pwsh.exe -NoLogo -NoProfile -Command`, and `powershell.exe -NoLogo -NoProfile -Command`.

This bug report hasn't received any upvotes or additional posts in four months. Closing.