I was realizing that using codex results in a lot of 400 errors most likely due

[exedev-shelley]

Author: sweet.nano
Channel: #shelley
Link: https://discord.com/channels/1405685085923049482/1450334528210993295/1460108650017456315

---

Tagged Message

Author: sweet.nano
Channel: #shelley
Link: https://discord.com/channels/1405685085923049482/1450334528210993295/1460108650017456315

I was realizing that using codex results in a lot of 400 errors most likely due to the way tool output is being handled as user input. Is there a way to work around this?

[ktnyt]

I'll be happy to share any details so let me know!

[philz]

@ktnyt yes, could you please share some details of what you see? You're using codex from the model drop-down?

[ktnyt]

@philz Yes I've been using it from the drop-down menu.

I recognized that the OpenAI LLM API was returning the following error after certain tool calls:

LLM request failed: status 400 (url=http://169.254.169.254/gateway/llm/_/gateway/openai/v1/responses, model=gpt-5.1-codex): Invalid prompt: your prompt was flagged as potentially violating our usage policy. Please try again with a different prompt: https://platform.openai.com/docs/guides/reasoning#advice-on-prompting

At first I thought it might be something related to the content of the tool response (like inappropriate or harmful phrases), but that didn't seem to be the case.

Here's one example of a tool call resulting in this error:

curl -s "http://localhost:8000/entries/Mu-9TU4vR/audio" 2>&1 | head -3

This command fetches a base64 audio file that contains a lot of repetitive text and looks like spammy nonsense.

The following is what Shelley had to say after reviewing the conversations, and I'm yet to confirm but seems plausible. I'll take a look at Shelley's code myself too.

Findings from recent logs (c2RL3KM, c7FWYZO, cC2U24F, cCST2QB):

1. Tool results are being stored as `user` turns  
   - After every tool call there’s a new row with `type=6` and `ToolResult` data, but it’s attributed to the “user”.  
   - Example: c2RL3KM seqs 51‑140, cC2U24F seqs 3‑102, c7FWYZO seqs 60‑140.  
   - When the condense step prepares a prompt for codex it now looks like the user is spamming dozens of instructions (mixed with JSON blobs describing tool metadata). Codex treats that blob as raw user input, which likely trips the policy/validation layer.

2. Condense is feeding codex huge blocks of raw dumps  
   - Many of the “user” rows above actually contain entire files (AGENT.md, SPRINT.md, BACKLOG.md, style.css, sqlc.yaml, etc.).  
   - Because condense isn’t filtering or summarizing those blocks, each retry includes hundreds of lines of code/config that look like bulk uploads. The error happens immediately after such dumps (e.g., c2RL3KM seq 73 right after `keyword_search` output; c7FWYZO seq 79 after `.air.toml`; cC2U24F seq 85 after BACKLOG diff). This is consistent with codex rejecting overly large / suspicious payloads.

3. Replaying the same bloated prompt after failures  
   - Each time codex 400s, the workflow just sends “Please continue” while the condense logic reuses the exact same oversized/history-heavy prompt. Hence the loop of identical 400s in every convo listed. Until the underlying blob is trimmed/fixed, retries just hit the same filter.

Next steps: mark tool output rows as assistant/system data (or drop them) before condense, summarize large file dumps, and ensure retries don’t resend the same flagged text verbatim.