Bash tool returns exit code 1 with no stdout/stderr on CachyOS (Arch Linux)

This is almost certainly caused by zsh/Powerlevel10k initialization interfering with the Bash tool's output capture, even though the tool runs under bash.

Root cause

Claude Code's Bash tool sources your shell profile on startup. If your ~/.bashrc or /etc/profile sources zsh-specific code (common on Arch/CachyOS), or if environment variables set by Powerlevel10k/oh-my-zsh alter terminal behavior (e.g., TERM, PROMPT_COMMAND, traps), the output pipe can break silently.

Fix to try

1. Add an early exit guard to ~/.bashrc:

# Top of ~/.bashrc — skip everything for non-interactive shells
[[ $- != *i* ]] && return

1. Also check /etc/bash.bashrc and /etc/profile.d/*.sh — CachyOS may have Arch-specific scripts that set traps or modify file descriptors:

# Check for anything that might interfere
grep -r 'trap\|exec\|PROMPT_COMMAND\|precmd' /etc/profile.d/ /etc/bash.bashrc 2>/dev/null

1. If that doesn't help, create a minimal bash profile for Claude Code:

# ~/.claude/bash_profile
# Minimal profile — no interactive shell setup
export PATH="/usr/local/bin:/usr/bin:/bin:$HOME/.local/bin"

Then in your Claude Code settings:

{
  "env": {
    "BASH_ENV": "~/.claude/bash_profile",
    "ENV": ""
  }
}

The key insight is that CachyOS bundles aggressive shell customizations by default — the fix is isolating Claude Code's bash subprocess from those customizations.

Thanks for the suggestion @yurukusa! I tried all three approaches:

1. ~/.bashrc guard — already had [[ $- != *i* ]] && return in both ~/.bashrc and /etc/bash.bashrc
2. Checked /etc/profile.d/ — found 80-systemd-osc-context.sh (systemd OSC 3008 context signalling) which injects escape sequences via PROMPT_COMMAND and PS0. Set TERM=dumb in Claude Code env settings to make it skip itself.
3. Created minimal BASH_ENV profile — set BASH_ENV and cleared ENV in settings.

Verified all env vars are correctly applied inside the Bash tool subprocess (TERM=dumb, BASH_ENV set, ENV empty). The systemd OSC script is being skipped. Still broken — every command returns exit code 1 with no stdout/stderr captured.

Key finding: commands do execute (proven by redirecting to file and reading it back), but the output pipe back to Claude Code is broken. Even echo "hello" returns exit 1 with empty output.

This appears to be a bug in Claude Code's output capture mechanism itself, not in shell initialization. The file-redirect workaround (cmd > file 2>&1; exit 0 then Read tool) continues to work reliably.

System: CachyOS (Arch), kernel 6.19.9-2-cachyos, zsh default shell, Claude Code latest.

Thanks for the thorough testing! Since shell initialization is ruled out and commands execute correctly (just output capture is broken), this is definitely a Claude Code platform bug, not a config issue.
The fact that output piping fails but file redirection works suggests the issue is in how Claude Code's Bash tool sets up the stdout/stderr pipe on CachyOS. A couple more data points that might help the team narrow it down:

1. Check if it's bun-specific: Claude Code uses bun's child_process — CachyOS ships with a znver4-optimized toolchain that may affect how bun spawns subprocesses. Try: bun -e "const r = require('child_process').execSync('echo hello'); console.log(r.toString())" to see if bun's pipe works at all.
2. Check for seccomp/Landlock: CachyOS with hardened kernels may enable seccomp filters that block certain syscalls in child processes. Check dmesg | grep -i seccomp after a failed Bash tool call.

Your file-redirect workaround is solid for now. This looks like it needs a fix in Claude Code's process spawning layer for CachyOS/Arch specifically.

Thanks for the follow-up suggestions @yurukusa!

Bun check: Claude Code bundles its own Bun runtime (confirmed: the claude binary is an ELF executable containing BUN_1.2). Installed system Bun (1.3.11) separately and tested:

bun -e "const r = require('child_process').execSync('echo hello'); console.log(r.toString())"

Result: works perfectly — hello, exit 0. So Bun's child_process pipe handling is fine on this system. The bug is specific to Claude Code's Bash tool implementation, not Bun on CachyOS/Arch in general. Possibly related to the older bundled Bun 1.2 vs current 1.3, or to how Claude Code wraps the subprocess.

Seccomp check: No seccomp denials in dmesg. CachyOS ships with systemd compiled with +SECCOMP support, but there are no audit entries for blocked syscalls. Kernel is 6.19.9-2-cachyos (standard, not hardened).

Summary so far:

• Shell initialization: ✅ ruled out (BASH_ENV, TERM=dumb, non-interactive guards all tested)
• Seccomp/Landlock: ✅ ruled out (no denials in dmesg)
• Bun child_process on this system: ✅ works fine (tested with Bun 1.3.11)
• Commands execute correctly: ✅ confirmed (file redirect proves execution works)
• Output pipe broken only inside Claude Code's Bash tool — not reproducible with standalone Bun

This narrows it down to Claude Code's specific process spawning/output capture layer, possibly the bundled Bun 1.2 or the wrapper around it.

Great debugging — you've conclusively isolated this to Claude Code's internal Bash tool pipe handling rather than system config. Since the file-redirection workaround works, that confirms the issue is in how CC captures stdout from its bundled Bun runtime on certain Linux distros. Hopefully the CC team picks this up as a confirmed platform bug.

Your systematic debugging is excellent — ruling out shell config, kernel security, system Bun, and narrowing it down to Claude Code's bundled Bun 1.2 pipe capture, all with concrete evidence at each step. This is the kind of root cause analysis that makes it easy for the platform team to fix.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Seems to be a duplicate of https://github.com/anthropics/claude-code/issues/19663.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.