Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

Running the install command "curl -fsSL https://openclaw.ai/install.sh | bash" from the documentation causes the script to hang indefinitely (for more than 20 minutes, and multiple times) and throw a "command not found" error for a truncated function name:
bash: line 2104: warn_shell_path_missing_di: command not found

The error was thrown only after waiting 20 minutes, pressing enter a couple times, then finally ctrl+c to end it.

Steps to reproduce

Simply run "curl -fsSL https://openclaw.ai/install.sh | bash" per documentation.
I ran this in wsl2 Ubuntu 24.04.1 LTS.

One host windows I did not get this problem(from what I remember atleast)

Expected behavior

According to the getting started documentation at https://docs.openclaw.ai/start/getting-started, this is the expected behavior:

Actual behavior

I didn't end up taking a photo when it happened, but I had to just remove the pipe and run ./install.sh manually (which is fine, but isn't expected per documentation).

However, I do have a copy of the error here:

[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash



^Cbash: line 2104: warn_shell_path_missing_di: command not found

[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash

^Cbash: line 2104: warn_shell_path_missing_di: command not found

[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash

The third time i ran curl, you can see that there is not any proceeding lines. That is because it was hanging. The previous two times I just did ctrl+c

OpenClaw version

OpenClaw 2026.4.26

Operating system

Ubuntu 24.04 LTS

Install method

curl?

Model

NA

Provider / routing chain

NA

Additional provider/model setup details

NA

Logs, screenshots, and evidence

bash
[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash



^Cbash: line 2104: warn_shell_path_missing_di: command not found

[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash

^Cbash: line 2104: warn_shell_path_missing_di: command not found

[andreu@Johnny: ~] curl -fsSL https://openclaw.ai/install.sh | bash

Impact and severity

Affected: Initial installation (with install.sh)
Severity: Annoying
Frequency: 3/3
Consequence: Failed installation via recommended piped curl command

Additional information

I cloned the repository and verified via grep that the function warn_shell_path_missing_dir() is spelled correctly in the source code(install.sh).

The truncation is presumably occurring at runtime due to stdin stealing.

Because the installer is interactive (i think through gum?), the UI prompts are attempting to read from stdin to capture user input, but, because the script is being piped via "curl ... | bash" , stdin is currently occupied by the script's stream.

What I think is the case here, is that, when an interactive prompt fires it ends up consuming a chunk of the incoming script stream. When bash resumes executing the pipe, it reads the mangled leftover string which in this case was "warn_shell_path_missing_di", and thus, throws a command not found error, and hangs because the prompt is disconnected from the actual TTY.

The workaround here that I used was this sequence of commands:

curl -fsSL https://openclaw.ai/install.sh -o install.sh
chmod +x install.sh
./install.sh

It's possible this is just some weird issue that only happens on my my end, but, my thought process for why it happened I think makes sense, and would theoretically be applicable to other users given it's the same code from the same repo.