Missing output of shell commands ran by the agent

This also happened to me starting in v0.59.0. 019aa132-d28f-7e63-9982-84035a140271.

Same here, started today after updating via Homebrew. I'm on latest macOS Tahoe 26.1, but ran without issues yesterday.

Sample output:

› Implement 1.16 in TODO.md


─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• I’m blocked: every shell command in /Users/<user>/Development/<project> returns exit code 0 with no stdout (even ls, rg,
  jj status, echo), so I can’t read the repo or the TODO/spec to see what “1.16” refers to. The only output I’ve seen was from a
  standalone pwd earlier.

  Date today: 2025-11-20.

  Can you check whether command output is being suppressed or share the text for TODO item 1.16 (and the matching spec section) so I
  can implement it? If there’s a preferred way to access files in this environment, let me know.

Here I reopened my shell just to be sure it wasn't a Mise tool issue.

› Try again now with this new shell


• Ran cd /Users/<user>/Development/<project> '&&' find . -name AGENTS.md -o -name AGENT_CONFIG.md -o -name CLAUDE.md '|' head
  │ -20
  └ (no output)

• Ran cd /Users/<user>/Development/<project> '&&' date '+%Y-%m-%d'
  └ (no output)

• Ran cd /Users/<user>/Development/<project> '&&' python - '<<PY' 'print(stdout test)' import sys "sys.stderr.write(stderr test\
  │ \n)" PY
  └ (no output)

• Explored
  └ List ls

─ Worked for 38s ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• Commands are still producing blank output in this shell (even with escalated permissions). I can’t read TODO.md, specs, or list
  files, so I can’t see what item 1.16 requires. Date: 2025-11-20.

  Could you share the text for TODO item 1.16 (and its matching spec section), or let me know how to access file contents in this
  environment? Once I can read the repo, I’ll implement it right away.

Any idea of why this would happen?

Small update; it works with unified_exec = true.

This should be fixed in 0.61.0 - going to close as a duplicate of #6940, but please let us know if you continue to see issues.