Greptile Summary

This PR adds a defensive sanitization layer that strips malformed </arg_value> XML-tag suffixes emitted by certain model providers (e.g. Qwen/DashScope) from tool call arguments, preventing corrupted exec commands and file paths. The fix is applied in two places: via stripXmlArgValueSuffixFromRecord inside normalizeToolParams (covering read/write/edit), and via a direct stripXmlArgValueSuffix call on params.command in the exec handler.

• Correct integration points: read/write/edit tools are covered through normalizeToolParams; exec command is handled directly since exec bypasses that normalizer.
• Regex quantifier is slightly narrow: >>{0,2}$ handles only 1–3 trailing > characters; using >*$ would defensively handle any count.
• Partial exec coverage: only params.command is sanitized in bash-tools.exec.ts; other string exec parameters (workdir, host, security, ask, node) receive no equivalent treatment and could be corrupted by the same provider bug.
• Test clarity: the normalizeToolParams test labelled "strips from command param" exercises a code path that doesn't match the actual exec flow (exec calls stripXmlArgValueSuffix directly), which could mislead future readers, though the assertion itself is valid.

Confidence Score: 4/5

• Safe to merge — the fix correctly addresses the documented issue with minimal risk of regression.
• The core logic is sound: the suffix strip is anchored to the end of the string, the fast-path includes guard prevents unnecessary regex work, and all the common corrupted forms are handled. Two minor gaps exist — the regex quantifier caps at 3 > chars and exec only sanitizes command — but neither is likely to affect real-world usage given the known provider behaviour described in the issue.
• src/agents/bash-tools.exec.ts — only command is sanitized; other string params are uncovered.

This is a comment left during a code review.
Path: src/agents/pi-tools.params.ts
Line: 96

Comment:
**Regex quantifier may leave residual `>` for unusual provider output**

The pattern `>>{0,2}$` matches `</arg_value>` followed by 0, 1, or 2 additional `>` characters — handling 1, 2, or 3 total `>` after `arg_value`. If a particularly malformed provider response happens to emit four or more trailing `>` (e.g. `</arg_value>>>>>`), the regex will only strip `</arg_value>>>` and leave the remainder in the value.

Using `>*` (zero-or-more) instead of `>{0,2}` would handle any number of trailing `>` characters without changing behavior for the documented cases:

```suggestion
const XML_ARG_VALUE_SUFFIX_RE = /<\/arg_value>>*$/;
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/bash-tools.exec.ts
Line: 230-232

Comment:
**Other string exec params not sanitized**

Only `params.command` is stripped, but the exec tool also accepts other string-typed parameters — `workdir`, `host`, `security`, `ask`, and `node` — that could be equally affected if the provider leaks the `</arg_value>` artifact into those values. A malformed `workdir` would silently break the working-directory resolution, which is hard to debug.

Consider sanitizing the full set of string exec params, or centralising via a shared helper similar to `stripXmlArgValueSuffixFromRecord`:

```typescript
// Strip all string exec params, not just command
for (const key of ["command", "workdir", "host", "security", "ask", "node"] as const) {
  if (typeof params[key] === "string") {
    params[key] = stripXmlArgValueSuffix(params[key]!);
  }
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 71c6c92}