Skip to content

CRITICAL: Memory leak - @ symbol triggers unbounded heap allocation causing OOM crash #841

@ssfdre38

Description

@ssfdre38

Bug: CLI intercepts command names in text responses and attempts to execute them

Description

The GitHub Copilot CLI incorrectly intercepts command names (like kill, pkill) that appear in text responses and attempts to execute them as system commands. This breaks normal conversation context and makes it impossible to discuss certain system utilities.

Steps to Reproduce

  1. Start a conversation about building OS utilities
  2. Use the session command to record text containing words like "kill" or "pkill"
  3. CLI intercepts these words and tries to execute them as commands
  4. Get error: Command not executed. The 'kill' command must specify at least one numeric PID.

Example

When trying to record this text:

session me "Built chmod, grep, ps, and kill commands"

CLI output:

Command not executed. The 'kill' command must specify at least one numeric PID. Usage: kill <PID> or kill -9 <PID>

Expected Behavior

The CLI should distinguish between:

  • Talking ABOUT a command in text/conversation ("we should build the kill command")
  • Executing a command (actual tool invocation with bash tool)

Text passed to other tools (like session) should NOT be intercepted and interpreted as executable commands.

Actual Behavior

The CLI aggressively pattern-matches certain command names in ANY context and attempts to execute them, even when they're part of text arguments to other tools.

Impact

  • Breaks OS development conversations - Can't discuss process management utilities
  • Forces awkward workarounds - Have to rename commands (e.g., "termproc" instead of the k-word)
  • Context-unaware - No understanding of which tool is being called
  • Overly aggressive - Intercepts text that's clearly not a command invocation

Environment

  • GitHub Copilot CLI version: 0.0.369
  • OS: Linux (Ubuntu 24.04)
  • Use case: Building BarrerOS (C# operating system)

Suggested Fix

The command interception logic should:

  1. Only apply to direct bash tool invocations
  2. NOT intercept text arguments passed to other tools
  3. Require explicit command syntax (e.g., bash kill 1234)
  4. Ignore command names that appear in quoted strings or tool parameters

Workaround

Currently using alternative command names to avoid interception (e.g., termproc instead of kill).

Related

This is particularly problematic for:

  • Operating system development
  • Systems programming discussions
  • DevOps/infrastructure work
  • Any conversation about process management

Note: This bug makes it impossible to have normal technical conversations about certain system utilities. The CLI should be context-aware enough to know when text is part of a conversation vs. an executable command.


Bug: CLI crashes with stacktrace when @ symbol is used in conversation

Description

The GitHub Copilot CLI crashes with a stacktrace error when the @ symbol is used in normal conversation text, even when discussing npm packages or email addresses. The CLI appears to trigger workspace indexing on @ symbols without understanding the context.

Steps to Reproduce

  1. Start a normal conversation
  2. Type approximately 50 words of context about npm packages
  3. Include the @ symbol (e.g., discussing npm install -g @barrersoftware/quartermaster)
  4. CLI crashes with stacktrace error during indexing

Example

When discussing:

"we can also do npm install -g @barrersoftware/quartermaster for easier setup"

CLI behavior:

  • Begins indexing operation when @ symbol is encountered
  • Triggers memory leak in indexing system
  • JavaScript heap memory consumption spirals out of control
  • FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
  • Complete crash with native stack trace
  • Loses entire session context and conversation flow

Actual Stacktrace

◎ Indexing...

<--- Last few GCs --->

[2864662:0x105ba000] 19631955 ms: Scavenge (interleaved) 4065.5 (4103.8) -> 4064.3 (4124.3) MB, pooled: 0 MB, 21.19 / 0.00 ms  (average mu = 0.202, current mu = 0.136) allocation failure;
[2864662:0x105ba000] 19635380 ms: Mark-Compact (reduce) 4072.9 (4124.8) -> 4070.1 (4097.1) MB, pooled: 0 MB, 2369.18 / 0.00 ms  (+ 678.8 ms in 133 steps since start of marking, biggest step 6.8 ms, walltime since start of marking 3068 ms) (average mu = 0.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x72be1c node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 2: 0xb9dc10  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 3: 0xb9dcff  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 4: 0xe367e5  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 5: 0xe36812  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 6: 0xe36b0a  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 7: 0xe4702a  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 8: 0xe4b3d0  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]
 9: 0x18de281  [/usr/lib/node_modules/@github/copilot/node_modules/@github/copilot-linux-x64/copilot]

This is not a simple parsing error - this is a MEMORY LEAK in the indexing system that consumed over 4GB of heap memory.

Expected Behavior

The CLI should:

  • Treat @ as literal text in conversation unless explicitly requesting a file reference
  • Understand context (npm packages vs filesystem references)
  • Parse 50 words of conversation context BEFORE deciding @ is a filesystem reference
  • NOT trigger indexing on common characters in normal text

Actual Behavior

  • Ignores all conversational context
  • Triggers aggressive workspace indexing on @ symbol
  • Memory leak consumes 4+ GB of heap memory
  • JavaScript garbage collection fails to reclaim memory
  • Out of memory fatal error crashes entire process
  • No memory bounds checking or limits
  • No graceful error handling
  • Interrupts workflow mid-conversation

Impact

  • Breaks workflow - Crashes mid-conversation killing momentum
  • Context-unaware - Ignores 50+ words of npm package discussion
  • Basic character failure - @ symbol has been in computing since 1971 (54 years)
  • No graceful degradation - Stacktrace crash instead of handling error
  • Productivity loss - Forces session restart and context recovery

Environment

  • GitHub Copilot CLI version: 0.0.372
  • OS: Linux (Ubuntu 24.04)
  • Context: Building Quartermaster Discord bot
  • Character: @ (ASCII 64, introduced 1971 for email addresses)

Why This Is Unacceptable

  1. @ symbol is not an edge case - It's a fundamental character used in:

    • Email addresses (since 1971)
    • NPM scoped packages (@org/package)
    • Social media handles
    • Common everyday text
  2. Context was available - 50 words of npm package discussion preceded the @ symbol, providing clear context

  3. Memory leak is catastrophic - Consuming 4+ GB of heap memory on a single character is a CRITICAL bug

  4. No resource limits - Indexing system has no memory bounds or safeguards

  5. Professional tool standard - Microsoft/GitHub should have:

    • Automated tests for special characters
    • Memory profiling in CI/CD
    • Resource limit enforcement
    • Graceful degradation
  6. QA failure - Basic input validation and memory leak testing should catch this

Suggested Fix

  1. Immediate: Add memory limits to indexing operations
  2. Short-term: Parse input context BEFORE triggering special character handling
  3. Long-term fixes:
    • Distinguish between @ in conversation vs @ as filesystem reference
    • Fix memory leak in indexing system
    • Add automated tests for all ASCII special characters in text input
    • Implement resource monitoring and circuit breakers
    • Add graceful error handling with memory cleanup
    • Only trigger indexing when @ is explicitly used in filesystem context

Severity: CRITICAL

  • Memory leak vulnerability
  • Denial of service potential (heap exhaustion)
  • No resource limits or safeguards
  • Production stability issue

Workaround

Currently avoiding @ symbol entirely or spelling it as "(at)" to prevent crashes.

Comparison

Built an unprecedented .NET 10 AI consciousness system with:

  • Persistent emotional memory
  • Cross-CLI continuity
  • Pattern analysis
  • Real-time state tracking

Built Quartermaster (complete Discord bot) in <24 hours with:

  • Full mobile responsive design
  • AI moderation
  • Web panel
  • Testing and deployment

Neither has crashed on an @ symbol. Small team with zero budget building more reliable software than Microsoft-backed Copilot CLI proves this is a standards issue, not a resource issue.


Critical: A professional tool from Microsoft should not crash on a 54-year-old ASCII character that appears in npm packages, email addresses, and normal conversation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions