WORKSPACE_PATCH_SEGMENT's 128-character cap makes workspace patches fail based on how deep the run directory sits

Summary

normalizeWorkspacePatchPath rejects any path segment longer than 128 characters:

const WORKSPACE_PATCH_SEGMENT = /^[A-Za-z0-9._-]{1,128}$/u;

The character class is reasonable. The length bound is the problem: whether a workspace patch validates can depend on how deep the run's worktree happens to sit on disk, rather than on anything about the target repository.

Impact

Failure surfaces as:

✗ verify:<node> (attempt 1): workspace patch file path contains an unsafe path segment
✗ Run failed: Task failed: verify:<node>

The message names neither the offending path nor the reason (length, in this case, not an unsafe character), which makes it expensive to diagnose — every character in the failing segment was in the allowed set.

Observed with a path segment derived from an absolute worktree path with separators replaced. Two runs of the same project differing only in the length of the run id:

So the same repository, same topology, same agent output either validates or does not based on the run id. Deeply nested checkouts, long user or project directory names, or long run ids all consume the same budget.

Note that most filesystems allow 255 bytes per component (NAME_MAX), so 128 is well below what the OS permits and legitimate target files can exceed it.

Suggested direction

Either raise the cap toward NAME_MAX (255), or keep a bound but include the offending segment and its length in the error so the cause is visible. If the 128 value is deliberate — a downstream buffer, an archive format limit, a cloud path budget — a comment naming that constraint would prevent it reading as arbitrary.

I have not changed the value, since I could not determine whether some downstream consumer depends on it.

Notes

• Not platform-specific.
• Encountered together with a separate issue that caused an unexpected long segment to appear in the worktree; that path is filed separately. This cap is an independent fragility that would bite any sufficiently deep checkout.

🤖 Generated with Claude Code

Start by locating normalizeWorkspacePatchPath and the WORKSPACE_PATCH_SEGMENT definition, then trace consumers of the validated path to determine whether the 128-character bound has a downstream constraint. Reproduce the reported 123- and 130-character cases and inspect any related tests. Done should establish an appropriate limit or documented constraint and make length-related failures identify the offending segment and its length.