[BUG] Claude Code 2.0.43+ exits immediately after rendering welcome screen on RHEL8

detailed similar issue in https://github.com/anthropics/claude-code/issues/12266

another similar issue is #11864

This still happening with 2.0.64

Same behavior for me with 2.0.76 on WSL Ubuntu. One thing to note is that if I type quickly, the input goes to the prompt and claude exits as I am typing.

Linux version 4.4.0-26100-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #7309-Microsoft Fri Jan 01 08:00:00 PST 2016

Still experiencing this on v2.1.3 over SSH on Ubuntu 18.04.6 LTS (glibc 2.27, zsh shell).

The welcome screen and theme selection menu render, then the process exits immediately (exit code 0). Non-interactive mode works fine. Downgrading to v2.0.42 resolves the issue. I also tested v2.0.43 which fails, confirming the bug was introduced in v2.0.43.

This appears to be related to #12507 (stdin consumption during shell snapshot creation).

I ended up debugging this with Claude Code on a Mac before I was aware that the problem was reported. It thinks it found the problem:

Please file an issue at https://github.com/anthropics/claude-code/issues with this information:

Title: Claude Code immediately exits on Red Hat 8.10 - stdin removed from epoll event loop

Description:
Environment:

• OS: Red Hat Enterprise Linux 8.10 (kernel 4.18.0-553.el8_10.x86_64)
• Terminal: macOS Terminal.app SSH'd to remote system
• SSH_TTY: /dev/pts/1
• TERM: xterm-256color
• Claude Code version: 2.1.5

Issue:
Claude Code displays the welcome screen and theme selection but exits immediately
without accepting keyboard input.

Root Cause:
strace reveals that stdin (fd 0) is added to epoll but immediately deleted:
epoll_ctl(4, EPOLL_CTL_ADD, 0, {events=EPOLLIN|EPOLLHUP|EPOLLONESHOT, ...}) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 0, NULL) = 0

After this, the program never receives keyboard input and exits after internal
timeouts expire.

Reproduction:

1. SSH from macOS to Red Hat 8.10 system
2. Run: ~/.local/bin/claude
3. Tool displays welcome screen but exits immediately

Attached: Full strace output showing the issue

Attach the /tmp/claude_epoll.txt file to the issue.

claude_epoll.txt

CC has not been crashing immediately after starting. However, I have been experiencing a couple of other, but possibly related, issues when running the native CC binary v2.0.43+ on 4.18.0-553.89.1.el8_10.x86_64:

1. CC would randomly fail to connect to stdio MCPs on start-up. Manually attempting to reconnect always succeeds. On the cases where it fails to connect to MCPs, the MCPs are launched but exit gracefully. strace shows that it's trying to write to a non-existent fd instead of using sendto to communicate with the MCPs.
2. CC terminates randomly when running bash commands.

These issues do not appear when using the npm package of CC or a native binary for versions <v2.0.42.

Additional Finding: Datadog SSI causes this issue

I debugged this extensively and found a specific cause on my system: Datadog Single Step Instrumentation (SSI).

Evidence

1. Datadog SSI intercepts all execve calls via /etc/ld.so.preload:
$ cat /etc/ld.so.preload
/opt/datadog/apm/inject/launcher.preload.so

2. The EPERM occurs in Datadog's wrapper, not Claude:

$ strace -f -e trace=execve,epoll_ctl claude 2>&1 | grep -E "execve|EPERM"

[pid 129412] execve("/opt/datadog/apm/inject/process", [..., "/bin/sh", "-c", "ldd /bin/ls"], ...)
[pid 129412] epoll_ctl(4, EPOLL_CTL_ADD, 3, {...}) = -1 EPERM (Operation not permitted)

3. Docker works because containers don't inherit /etc/ld.so.preload from host.

Root Cause

Datadog's execve hook wraps every shell command with /opt/datadog/apm/inject/process, which fails on epoll_ctl for fd 3.

Workarounds

- Run in Docker

Is this issue any closer to be looked into? There have been a grand total of 54 releases between 2.0.42 and today.

Wanted to share my test.

Turns out on ROCKY8 (RHEL8) is not letting me run Claude with the latest.

I think it has something to do with it trying to execute something and rhel saying nah cannot do that.

I am digging into it but if I run as root it works perfect or if I am in my user I can go into /tmp direcotry and it works. So might have to do with the /etc/fstab configuration for executable or somthing.

Additional findings - Home Directory Workaround

I've done extensive debugging on Rocky Linux 8.10 (RHEL8) and discovered the issue is specifically triggered when running from the user's exact home
directory ($HOME).

Workaround: Run from any subdirectory instead of downgrading:
mkdir -p ~/projects && cd ~/projects && claude # works
cd /tmp && claude # works
cd ~/anything && claude # works
cd ~ && claude # fails - stdin removed from epoll

Environment:

• Rocky Linux 8.10 (glibc 2.28, kernel 4.18)
• Claude Code 2.1.19
• Non-root user via SSH

What triggers it:

• Running from exact $HOME path (/home/username)
• The home directory detection/onboarding code path appears to trigger the stdin consumption bug

What works:

• Any subdirectory of home (~/projects, ~/test)
• /tmp or any other path
• Running as root from /root
• Non-interactive mode (claude -p)
• Same user, same session, same TTY - just different working directory

This suggests the stdin/epoll removal identified by @gregfife-cdi is triggered specifically by Claude's home directory handling code, not a general startup issue.

If other could confirm this is the same thign they are seeing please let me know. If not, I will make a new issue.

same issue on WSL2 Debian 12

I'll add to Brandon's extensive debugging that running in $HOME with set CLAUDE_CODE_OAUTH_TOKEN env variable is a workaround for me

I've had this problem for some months now. I tried to have claude code diagnose the issue remotely from my macbook, and it failed. The only way to resolve it was to revert to 2.0.41.

Well now that claude code is writing 100% of the code and there's slim to little chance there aren't claude agents managing a 5,000 issue backlog, our chances of getting any eyes on this... You might as well go out and buy a lottery ticket.

Still happening on Windows in version 2.1.20, and it is not dependent on being in one's home directory. And the VS Code plug-in is broken, so Claude is unusable on Windows as far as I can tell.

Realized that when using the native binary, the interactive workspace trust dialogue does not show up for new projects -- not sure in which version this has started happening. Instead, it's defaulting to adding "hasTrustDialogAccepted": false, in ~/.claude.json. However, it's showing up every time if Claude Code is launched from the home dir (same as #18942).

In v2.1.27, CC started crashing after displaying the trust dialogue, if launched from the home dir, sometimes even freezing the terminal. In v2.1.30, it's just exiting with code 0, no matter where it's launched from (same as #23164).

Does this reproduce on the npm installation?

Would be really helpful if you could check if strace / perf trace / nttrace yields anything of note

So, I was having this problem, and it seems like the immediate crash after showing the banner only happens when starting in a directory that is not in a git repo. Once I do I "git init" in the directory, claude doesn't crash.

@dvanblerkom's solution works. And it finally makes some part of this bug behavior reproducible!

I fixed this at first by reverting to 2.0.41 (as I noted in #11864 here https://github.com/anthropics/claude-code/issues/11864#issuecomment-3858651741) and disabling auto-upgrades. I had to switch login accounts, which forced an auto-upgrade and broke things again.

If I try to run claude on my home directory, it fails. If I try to run it in any directory that is not a git repository, it fails. If I run it in a directory with a git repository, it works. If I cd back to my home directory and do git init, it works.

Given the noise of issues on this repository, it's not clear to me that this information will ever filter through to a Claude Code developer's to-do list, but it's written here for prosperity.

Here is a movie that shows it: https://astrowizici.st/claude-bug.mov

For what it's worth, I had some back-&-forth with Claude support on this and the utter brokenness of Claude Code on Windows. I directed the rep (real or fake? who knows) to this issue, which "he" acknowledged and thanked me for.

If you engage Claude itself on either this or the other problem that kills it on Windows, you'll get, 'Oh, you've hit THAT known problem..."

I've been a paying "customer" for weeks now, and have yet to be able to use the product on Windows. I hope people are demanding refunds.

@Stokestack it's worth noting that the default installers for CC are pre-configured to pull latest and not stable. I'm not able to help you on your Windows OS, but I can tell you it's important to make sure the version of CC you're running is pulling from the stable branch and not latest.

My $0.02

I can confirm that we have the issue in RHEL8, and that doing git init fixes the issue. Even easier, creating an empty .git folder also fixes the issue.

Hopefully this gets solved quickly because it severely impacts Claude terminal usability on our side.

Can confirm anything after 2.0.41 will exit on RHEL8,

Work-around

Do a "git init " or a "mkdir .git "and then starting claude resolves the issue

Tried both "git init" and creating the .git directory on Alpine Linux (RHEL) and it doesn't solve it for me.

Environment: OS: RHEL (Red Hat Enterprise Linux), SSH connection
Claude Code: v2.1.63 (native binary)
Auth: ANTHROPIC_API_KEY with LiteLLM gateway (ANTHROPIC_BASE_URL)
Regression: v2.1.29 works, v2.1.30+ silently exits (code 0) outside git repo.
Workaround: "git init " or "mkdir .git " in the working directory fixes it.

Should no longer be occurring in Claude Code 2.1.76.

@ant-kurt still affected on 2.1.79 though I can't guarantee every part of what I'm seeing is identical to this issue. It exits in three to ten seconds with no error and --debug reveals nothing.

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.