[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. Commands do not execute or return output.

Environment: macOS 15.6.1 M1 Max, Copilot CLI (~~v0.0.354~~)0.0.358

@kapral18

@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

@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

@EvanBoyle same with hello world

Ah, I see from your other screenshots that this is with haiku?

@EvanBoyle

@EvanBoyle nope, happens across all models.

@RyanHecht

@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

@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.

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 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)

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

@shibbas @dereklegenzoff @EvanBoyle any update on this?

I just tried latest version 0.0.369 and it's still the same

I'm having a similar issue.

I'm running the latest version v0.0.395

I'm running Windows Server 2025 with WSL.

My build environment is Windows so I have a compile.sh in my folder that just does this:

#!/usr/bin/bash
cmd.exe /c build.cmd java

I can run that script in WSL and it works.
I can start copilot and I can run the script as !compile.sh and it works - I see all the compiler output.
I tell copilot to run it and copilot will run it but it then just hangs, it never comes back. It keeps monitoring the run but there is no output ever.

Okay I just tried something and I got it working.

Looks like it is having issues reading the stdout

I changed my script from:

#!/usr/bin/bash
cmd.exe /c build.cmd java

to

#!/usr/bin/bash
rm compile_output.txt
cmd.exe /c build.cmd java > compile_output.txt

And I tell copilot to read the output file when done.

This works 100% - I now have feedback from my build and it could see compiler errors and fixes it and retries the build etc.

Here is a sanitized excerpt from a failing Copilot CLI shell session state (~/.copilot/session-state/fd75ead5-7e03-437b-9341-cf8b87ecc0b8/events.jsonl).

Copilot CLI version: 0.0.418
Repro prompt: “Use bash with mode=async to run: sleep 2; echo done. Then call read_bash with delay 3 seconds on the returned shellId and report output.”

Notable behavior:

bash returns a “still running” message with a negative duration (-0.001 seconds)
Immediately after, read_bash fails with <no active shell sessions> for the returned shellId

[
  {
    "type": "session.start",
    "data": {
      "sessionId": "fd75ead5-7e03-437b-9341-cf8b87ecc0b8",
      "copilotVersion": "0.0.418",
      "startTime": "2026-02-25T21:39:12.798Z",
      "context": {
        "repository": "kapral18/kibana",
        "cwd": "<redacted>",
        "gitRoot": "<redacted>",
        "branch": "<redacted>"
      }
    }
  },
  {
    "type": "user.message",
    "data": {
      "content": "Use bash with mode=async to run: sleep 2; echo done. Then call read_bash with delay 3 seconds on the returned shellId and report output."
    }
  },
  {
    "type": "tool.execution_start",
    "data": {
      "toolCallId": "toolu_vrtx_018jFJkVLJBjNKRZpP8CAGkh",
      "toolName": "bash",
      "arguments": {
        "command": "sleep 2; echo done",
        "description": "Test async bash with sleep",
        "mode": "async"
      }
    }
  },
  {
    "type": "tool.execution_complete",
    "data": {
      "toolCallId": "toolu_vrtx_018jFJkVLJBjNKRZpP8CAGkh",
      "toolName": "bash",
      "success": true,
      "result": {
        "content": "<command with shellId: 0 is still running after -0.001 seconds. The command is still running but hasn't produced output yet. It may be waiting for input or still processing. Use read_bash to continue waiting, write_bash if you think it needs input, or stop_bash to stop it.>",
        "detailedContent": "<command with shellId: 0 is still running after -0.001 seconds. The command is still running but hasn't produced output yet. It may be waiting for input or still processing. Use read_bash to continue waiting, write_bash if you think it needs input, or stop_bash to stop it.>"
      },
      "toolTelemetry": {
        "properties": {
          "customTimeout": "false",
          "executionMode": "async",
          "detached": "false"
        },
        "metrics": {}
      }
    }
  },
  {
    "type": "tool.execution_start",
    "data": {
      "toolCallId": "toolu_vrtx_01QvEdVaoqgrE1KVvvPCWKZk",
      "toolName": "read_bash",
      "arguments": {
        "shellId": "0",
        "delay": 3
      }
    }
  },
  {
    "type": "tool.execution_complete",
    "data": {
      "toolCallId": "toolu_vrtx_01QvEdVaoqgrE1KVvvPCWKZk",
      "toolName": "read_bash",
      "success": false,
      "error": {
        "message": "Invalid shell ID: 0. Please supply a valid shell ID to read output from.\n\n<no active shell sessions>",
        "code": "failure"
      },
      "toolTelemetry": {}
    }
  }
]

I enabled interactive shell logs via --log-interactive-shells and it looks like the failure happens before the user command runs, during shell session initialization.

Session directory (local): ~/.copilot/session-state/334c9413-42ac-463c-b109-5b8014099f59/

From shell-logs/shell-0-*.log (same pattern in shell-1-*.log):

[INFO] PTY spawned: file=bash, args=["--norc","--noprofile"], pid=...
[INFO] initializeShellEnvironment: sending init command
[INFO] executeCommand: command="PS1=\"\";PS2=\"\";unset HISTFILE", timeout=5000ms
[ERROR] Shell environment initialization failed: Error: Command timed out
[INFO] PTY process exited: exitCode=0, signal=1, commandInProgress=false, bufferLength=0

So the bash tool is failing during the init step, the session gets shut down, and then read_bash/list_bash correctly see <no active shell sessions>.

Also seeing unexpected PTY output in the same logs like:

The default interactive shell is now zsh.

even though the spawned shell is bash --norc --noprofile.

Finally found the system-side culprit that makes bash / read_bash sessions fail.

Root cause

My ~/.inputrc had this binding:

Control-j: menu-complete

In readline, Control-j is the LF/newline byte (\n, 0x0A). Copilot’s PTY driver injects commands into an interactive /bin/bash by writing text + LF as the “press Enter” delimiter.

So instead of “accept-line”, bash/readline interprets Copilot’s injected newlines as menu-complete, which causes:

BEL beeps (^G) / redisplay noise
random completion text appearing in the buffer
Copilot’s wrapped init command never actually running
then executeCommand(... timeout=5000ms) → shell shutdown → read_bash sees <no active shell sessions>

How we proved it

A minimal PTY harness reproduces the exact corruption when sending LF (\n) into bash --norc --noprofile with that .inputrc binding.

Two independent fixes make it work immediately:

send CR (\r) instead of LF for “Enter”
or disable readline config with INPUTRC=/dev/null

Removing the Control-j binding from ~/.inputrc also fixes it.

Workaround for affected users

Quick workaround:

env INPUTRC=/dev/null copilot

Or remove / change the Control-j binding in ~/.inputrc.

Suggestion for copilot-cli

To be robust against user readline configs, consider sending carriage return (\r) rather than \n when simulating Enter in PTY interactive shells (or set INPUTRC=/dev/null for the tool’s internal shell sessions).

(Separate note: macOS /bin/bash also prints the “default interactive shell is now zsh” banner in PTY-interactive mode; it’s noisy but not the root cause here.)

@SteveSandersonMS

@SteveSandersonMS @dereklegenzoff @shibbas @EvanBoyle feel free to close this as original issue is resolved unless you want to track this for a follow up fix for carriage return suggestion.

@kapral18

Excellent work @kapral18! 🥇 I've had the same problem for weeks. Your solution fixed it.

Closing — reporter confirmed the original issue is resolved.

@kapral18

@kapral18 @toby why has this issue been closed? I'm still experiencing the same error in the latest version

$ copilot --version
GitHub Copilot CLI 1.0.31.
Run 'copilot update' to check for updates.

Navigation Menu

Repository navigation

[BUG] Bash execution environment hangs - all commands timeout #575

9 remaining items

Root cause

How we proved it

Workaround for affected users

Suggestion for copilot-cli

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Bash execution environment hangs - all commands timeout #575

Description

Activity

EvanBoyle commented on Nov 15, 2025

kapral18 commented on Nov 16, 2025

kapral18 commented on Nov 16, 2025

EvanBoyle commented on Nov 16, 2025

kapral18 commented on Nov 16, 2025

kapral18 commented on Nov 17, 2025

markus1189 commented on Nov 17, 2025

kapral18 commented on Nov 18, 2025

Foo-x commented on Nov 18, 2025

kapral18 commented on Nov 18, 2025

EvanBoyle commented on Nov 18, 2025

9 remaining items

markus1189 commented on Nov 22, 2025

kapral18 commented on Nov 25, 2025

kapral18 commented on Dec 2, 2025

kapral18 commented on Dec 14, 2025

amkza commented on Jan 27, 2026

amkza commented on Jan 27, 2026

kapral18 commented on Feb 25, 2026

kapral18 commented on Feb 25, 2026

kapral18 commented on Feb 26, 2026

Root cause

How we proved it

Workaround for affected users

Suggestion for copilot-cli

kapral18 commented on Feb 26, 2026

jonas054 commented on Mar 7, 2026

toby commented on Mar 17, 2026

mvillafuertem commented on Apr 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions