[BUG] Bash execution environment hangs - all commands timeout
All shell commands hang indefinitely and timeout regardless of complexity. Tested with simple commands like echo "Hello, world!" and brew info losslesscut. Commands do not execute or return output.
Environment: macOS 15.6.1 M1 Max, Copilot CLI (~v0.0.354~)0.0.358
@kapral18 we made some major updates to the shell tool in v0.0.355. Would you mind upgrading to latest and seeing if that fixes your problem. Shell session management was one thing specifically that was improved.
@kapral18 we made some major updates to the shell tool in v0.0.355. Would you mind upgrading to latest and seeing if that fixes your problem. Shell session management was one thing specifically that was improved.
@EvanBoyle I updated to latest
@EvanBoyle same with hello world
Ah, I see from your other screenshots that this is with haiku?
@EvanBoyle nope, happens across all models.
@RyanHecht maybe you have any ideas ? I would really appreciate being able to use copilot-cli, if you need any additional specific diagnostics data let me know
Same here on x86 linux (nixos). 354 still works, and all builds up to 358 are broken for me too
@tidy-dev any ideas?
Same here on WSL2 with 0.0.360. 0.0.354 works.
I was on 0.0.354 when I opened the issue. So for me it didn't work even then. But im on amd mac
Thank you all for the reports. We have some tool instructions updates we can roll out that will hopefully help smooth this out.
Still broken in 0.0.361
Still absolutely broken
Hi @kapral18 - would you be able to do Ctrl+r on the repro and share a screenshot with the expanded output?
@shibbas
Thank you! We rolled out some tool instructions updates today if you want to try, but @dereklegenzoff is going to dig deeper here.
Tool instructions will not fix this IMHO. There is a problem with the node process not being connected to the spawned bash's input/output and that's why they hang and nothing happens
Yeah. Agreed. Didn't think the tool instructions would help here - they help for some models we observed hallucinating the read_bash session_id and smoothing out session reads with parallel tools. We would be digging in deeper here.
I found the problem in my setup:
Copilot found a bash that did not have readline support, therefore non-interactive and that made it fail.
Background:
As I'm on nix, and was running everything in a nix shell, the bash was not the bashInteractive version, but a minimal version without readline support. Adding bashInteractive from nixpkgs fixed it for me 🎉
So if somebody else has the problem and wants to check if bash has readline:
ldd $(which bash) | grep readline
libreadline.so.8 => /nix/store/wy4jk1cb5l00rlvjb1kgwbsxz5kggm8s-readline-8.3p1/lib/libreadline.so.8 (0x00007f94fe9d4000)
libhistory.so.8 => /nix/store/wy4jk1cb5l00rlvjb1kgwbsxz5kggm8s-readline-8.3p1/lib/libhistory.so.8 (0x00007f94fe9c5000)
I found the problem in my setup:
Copilot found a
bashthat did not have readline support, therefore non-interactive and that made it fail.Background:
As I'm on nix, and was running everything in a
nix shell, the bash was not thebashInteractiveversion, but a minimal version without readline support. AddingbashInteractivefrom nixpkgs fixed it for me 🎉So if somebody else has the problem and wants to check if bash has readline:
ldd $(which bash) | grep readlinelibreadline.so.8 => /nix/store/wy4jk1cb5l00rlvjb1kgwbsxz5kggm8s-readline-8.3p1/lib/libreadline.so.8 (0x00007f94fe9d4000) libhistory.so.8 => /nix/store/wy4jk1cb5l00rlvjb1kgwbsxz5kggm8s-readline-8.3p1/lib/libhistory.so.8 (0x00007f94fe9c5000)
that's a nix specific problem.
Other systems have full bash package with readline support. So the problem persists for me on Mac with both native and brew versions of bash.
@shibbas @dereklegenzoff @EvanBoyle any update on this?
I just tried latest version 0.0.369 and it's still the same