Guard spawn agent activity labels

[itkonen]

Sometimes Codex provides sub-agent activity labels that are extremely long, nonsensical, or repeat the same text over and over. This bloats the dialogue and can also pollute the tool-call history that later model turns may see. This PR adds a small guardrail to prevent that issue.

---

The summary below was generated by AI.

• I added a entry in changelog under unreleased section.
• This is not an AI slop.

Summary

• Normalize spawn_agent activity arguments by trimming, collapsing whitespace, truncating overly long labels, and omitting blank or non-string labels.
• Apply normalization before pre-tool-call hooks and again after hook-modified arguments so stored/replayed tool-call arguments stay clean.
• Format subagent summaries without a trailing activity suffix when the activity is omitted.

Verification

• clojure -M:test --focus eca.features.tools.agent-test
• clj-kondo --lint src/eca/features/tools/agent.clj src/eca/features/chat/tool_calls.clj test/eca/features/tools/agent_test.clj

[ericdallo]

@itkonen Can you give me a example from eca stderr or something to understand better how codex behave?

[itkonen]

@ericdallo There's actually nothing in the stderr.

The main issue is with the user-facing labels printed out in the chat. Sometimes the label is just gibberish or exotic unicode symbols, but sometimes it's really, really long. Like here in this subagent call the label was over 13000 characters, filling multiple pages on my screen:

reviewer: reviewing label guardrail fixes upstream quality and downstream model context contamination risks with very long label handling and schema side effects repeated repeated repeated repeated repeated ... [about 13000 characters in this label!] ... repeated repeated repeated (6 steps) ✅ 4m 30s

A secondary issue is that this long label might get passed forward in later chat turns, filling up the LLM context window.

My guess is that Codex uses a small specialized model to generate the tool calls that ECA receives, and that model knows only how to write the tool call payload but easily fails at writing sensible action labels. And that model might get stuck in a loop repeating a word or a phrase over and over again.

So in this PR implements minimal guardrails to limit the length of the label and prevents it from bloating further model requests. The user will still see the gibberish but at least it will not harm the workflow.

[ericdallo]

Ah got it, yeah that's crazy! but makes sense

[ericdallo]

@itkonen but I'm not sure this is the best way to solve this, IIUC the problem is that some summary texts from LLM could be huge, affectin tool call labels, instead of normalizing that, I think we could just limit the summary text here, WDYT?

[itkonen]

@ericdallo I think that would only fix the UI problem.

My understanding is that the misbehaving activity label would still get stored in chat history, which could later be replayed back to the Responses API as part of the tool_call arguments, filling up the model context. But I cannot read the code well enough to say for sure.

[ericdallo]

Hum, yes, I thought would be ok for UI, but since this goes to LLM again and could be huge for some reason, I think it's ok to strip it

[zikajk]

I absolutely agree that this is a problem.
But I'm wondering if it wouldn't be better to improve the parameter descriptions and reject the tool call if they aren't followed. I haven't experimented with it yet, but I'm a bit worried we'd just end up trimming the nonsense that Codex sends our way. WDYT?

[itkonen]

@zikajk That's a valid point, but the weird thing is that the actual arguments in these tool calls might be completely sane, even if the activity label is gibberish. I wouldn't want break the workflow because of the silly labels. But it might be worth thinking if something could be done to prevent the gibberish - like giving more context for the activity label.