Describe the bug
Copilot CLI's built-in rg and glob search tools crash before searching when the bundled ARM64 ripgrep binary runs on a Linux host configured with 64 KiB memory pages. The binary aborts during jemalloc initialization with Unsupported system page size, preventing repository search from working.
Affected version
1.0.86
Steps to reproduce the behavior
-
Use an ARM64 Linux host with a 64 KiB kernel page size.
-
Run the ripgrep binary shipped with Copilot CLI:
$ ~/.cache/copilot/pkg/linux-arm64/1.0.86/ripgrep/bin/linux-arm64/rg --version
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 160 bytes failed
Aborted (core dumped)
-
Invoke Copilot CLI's rg or glob search tool. It produces the same jemalloc error and returns no search results.
The affected host reports:
$ getconf PAGESIZE
65536
$ uname -srm
Linux 6.17.0-1014-nvidia-64k aarch64
The process exits with status 134.
Expected behavior
The built-in search tools should work on ARM64 Linux hosts with 64 KiB pages, or Copilot CLI should automatically fall back to a compatible search backend when the bundled ripgrep binary cannot start.
Additional context
Related issue
This was previously reported in github/copilot-cli#658, which was closed after the USE_BUILTIN_RIPGREP=0 workaround was identified. The issue remains reproducible, and later commenters reported the same failure even after applying the workaround.
We are opening this new issue because the workaround is not a good long-term fix: it is not discoverable to users, requires restarting Copilot CLI with a special environment variable, and does not address the incompatible bundled binary. Multiple users are encountering the same failure, making search unreliable or unusable on affected ARM64 systems.
Machine and operating system
- Hardware: Dell Pro Max with Station GB300
- OS: Ubuntu
24.04.5 LTS
- Kernel:
6.17.0-1014-nvidia-64k
- Architecture:
aarch64 / ARM64
- Kernel configuration:
CONFIG_ARM64_64K_PAGES=y
- Runtime page size:
65536 bytes
Comparison with working search binaries
My own ripgrep works on the same host:
$ /home/linuxbrew/.linuxbrew/bin/rg --version
ripgrep 15.2.0
$ /home/linuxbrew/.linuxbrew/bin/rg --files ~/dev/nigel-models/src/nigel/nigel-0.6
# succeeds
The bundled tgrep binary also starts and searches successfully. This isolates the failure to the bundled ripgrep binary and its allocator configuration rather than to the repository or the kernel's general ability to run search tools.
Workaround
The Copilot CLI changelog documents USE_BUILTIN_RIPGREP as a way to use ripgrep from PATH. Starting a new session with the system binary avoids the crash:
USE_BUILTIN_RIPGREP=false copilot
Suspected cause
The bundled ARM64 ripgrep binary is statically linked and contains jemalloc. It appears to have been built with a 4 KiB page-size assumption, while the host kernel uses 64 KiB pages. jemalloc therefore aborts during process initialization before ripgrep reaches its normal argument parsing.
Potential fixes include shipping ripgrep without jemalloc, building jemalloc/ripgrep with 64 KiB page support (lg-page=16), or detecting this platform and selecting the system ripgrep or tgrep backend.
Describe the bug
Copilot CLI's built-in
rgandglobsearch tools crash before searching when the bundled ARM64 ripgrep binary runs on a Linux host configured with 64 KiB memory pages. The binary aborts during jemalloc initialization withUnsupported system page size, preventing repository search from working.Affected version
1.0.86Steps to reproduce the behavior
Use an ARM64 Linux host with a 64 KiB kernel page size.
Run the ripgrep binary shipped with Copilot CLI:
Invoke Copilot CLI's
rgorglobsearch tool. It produces the same jemalloc error and returns no search results.The affected host reports:
The process exits with status
134.Expected behavior
The built-in search tools should work on ARM64 Linux hosts with 64 KiB pages, or Copilot CLI should automatically fall back to a compatible search backend when the bundled ripgrep binary cannot start.
Additional context
Related issue
This was previously reported in github/copilot-cli#658, which was closed after the
USE_BUILTIN_RIPGREP=0workaround was identified. The issue remains reproducible, and later commenters reported the same failure even after applying the workaround.We are opening this new issue because the workaround is not a good long-term fix: it is not discoverable to users, requires restarting Copilot CLI with a special environment variable, and does not address the incompatible bundled binary. Multiple users are encountering the same failure, making search unreliable or unusable on affected ARM64 systems.
Machine and operating system
24.04.5 LTS6.17.0-1014-nvidia-64kaarch64/ ARM64CONFIG_ARM64_64K_PAGES=y65536bytesComparison with working search binaries
My own ripgrep works on the same host:
The bundled
tgrepbinary also starts and searches successfully. This isolates the failure to the bundled ripgrep binary and its allocator configuration rather than to the repository or the kernel's general ability to run search tools.Workaround
The Copilot CLI changelog documents
USE_BUILTIN_RIPGREPas a way to use ripgrep fromPATH. Starting a new session with the system binary avoids the crash:Suspected cause
The bundled ARM64 ripgrep binary is statically linked and contains jemalloc. It appears to have been built with a 4 KiB page-size assumption, while the host kernel uses 64 KiB pages. jemalloc therefore aborts during process initialization before ripgrep reaches its normal argument parsing.
Potential fixes include shipping ripgrep without jemalloc, building jemalloc/ripgrep with 64 KiB page support (
lg-page=16), or detecting this platform and selecting the system ripgrep ortgrepbackend.