Timeout compatibility issues when calling tools.

[n-WN]

What version of Codex is running?

codex-cli 0.63.0

What subscription do you have?

plus

Which model were you using?

gpt-5.1

What platform is your computer?

Darwin 24.5.0 arm64 arm

What issue are you seeing?

Frequent issues are related to the introduction of the timeout parameter.

• Ran bash -lc 'jq ".challenges[0:10]" challs.json | sed -n "1,120p"','timeout_ms':600000,'workdir':'/Users/test/my/subgroup'}

zsh:1: parse error near `}'

What steps can reproduce the bug?

You just need to let Codex execute the command, and it will automatically add the timeout parameter. However, there's an issue with how this parameter is parsed; once, it wrote "timeout" into a git commit message

What is the expected behavior?

No response

Additional information

No response

[n-WN]

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

[muyuanjin]

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.

[n-WN]

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.

I'll finish this part.

[n-WN]

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.

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?

[dylan-hurd-oai]

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

[n-WN]

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

[muyuanjin]

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`.