CI retry helper breaks when task mutates PATH

Context

The generated CI retry helper in genie/ci-workflow.ts still shells out to sed, grep, head, and tr after running the wrapped task via eval "$1".

On our self-hosted runners this leads to intermittent failures like:

.../_temp/<id>.sh: line 56: sed: command not found
.../_temp/<id>.sh: line 61: grep: command not found
.../_temp/<id>.sh: line 64: grep: command not found

Current behavior

The helper assumes those tools remain available on PATH after the wrapped task exits.

In practice that is not reliable because the wrapped command runs in the same shell and can mutate PATH before the helper reaches its post-failure log parsing.

I verified:

• the generated helper still emits those commands in genie/ci-workflow.ts
• the runner service itself does start with sed and grep available
• so the failure is not a missing host package, but the helper depending on ambient PATH after eval

Desired behavior

The retry helper should not depend on mutable ambient PATH after the wrapped task runs.

A principled fix would be one of:

• resolve required tool paths before eval and call them explicitly afterward
• restore a known-good helper PATH before log parsing
• or better, avoid external text tools in the retry parser entirely where practical

Why this matters

We already fixed an earlier portability bug in this helper (perl), but this is the broader remaining issue in the same area. The retry wrapper can still fail while trying to diagnose the real task failure, which makes CI logs misleading and brittle.

Filed by an AI assistant on behalf of @schickling

Start in genie/ci-workflow.ts by reading how the generated retry helper runs eval "$1" and then invokes sed, grep, head, and tr during post-failure log parsing. Ensure the generated helper no longer relies on the task's mutated PATH, and verify the emitted script preserves retry diagnostics when those tools are unavailable through ambient PATH.