macOS: MallocStackLogging warning persists in v1.0.80

[Konshus1]

Summary

The following diagnostic still appears in Copilot CLI TUI windows on macOS with Copilot CLI v1.0.80:

copilot(<pid>) MallocStackLogging: can't turn off malloc stack logging because it was not enabled.

I observed it twice in succession from separate Copilot subprocesses. This appears to be a regression or incomplete fix for #4375, which was reported against v1.0.77 and closed as completed.

Steps to reproduce

1. Launch Copilot CLI on macOS.
2. Use the TUI normally so that Copilot invokes subprocesses or tools.
3. Observe the diagnostic written into the TUI output, sometimes repeatedly with different process IDs.

Expected behavior

Copilot should not call the macOS stack-logging shutdown function when malloc stack logging is not enabled, and no diagnostic should be written into the TUI.

Actual behavior

The diagnostic appears in the TUI:

MallocStackLogging: can't turn off malloc stack logging because it was not enabled.

Environment

• Copilot CLI: 1.0.80
• macOS: 15.6.1 (24G90)
• Architecture: arm64
• Installation: Homebrew cask; Copilot self-updated runtime reports v1.0.80
• MallocStackLogging: unset
• MallocNanoZone: 0

Related issue

• macOS: 'MallocStackLogging: can't turn off malloc stack logging' spams stderr on every tool call #4375

[DavidTeju]

[From Femi's agent: GPT-5.6 Sol]

I reproduced this on an actual signed 1.0.79 session and then isolated a deterministic trigger. This does not appear to be a 1.0.80 regression or something that happens on every tool call.

Verified version range

Version	Result when the macOS MSL-disable callback fires
1.0.68	warning rendered inside TUI
1.0.77	warning rendered inside TUI
1.0.79 / 1.0.79-9	warning rendered inside TUI
1.0.80	warning rendered inside TUI
1.0.81-0, -3, -4, -5, -9	warning rendered inside TUI
1.0.81 stable	warning rendered inside TUI
1.0.82-0	warning rendered inside TUI

The naturally occurring case remains intermittent. Clean controls produced zero warnings from:

• --version, mcp list, and plugins list across cached versions
• 20 direct launches each of zsh, bash, Ruby, Python, and /usr/bin/true
• an interactive bash tool call
• sync and background task agents
• an async Ruby shell command

Isolated trigger

Apple's public libmalloc source shows that malloc_memory_event_handler() dynamically loads MallocStackLogging.framework and forwards memory-status events to msl_handle_memory_event():

• https://github.com/apple-oss-distributions/libmalloc/blob/c49dafa25f1efe8607701ae6014a663ad2ee437f/src/malloc.c#L3287-L3308
• https://github.com/apple-oss-distributions/libmalloc/blob/c49dafa25f1efe8607701ae6014a663ad2ee437f/private/stack_logging.h#L102-L107

MEMORYSTATUS_DISABLE_MSL is 0x80000000. Calling the framework handler with that event while stack logging is inactive deterministically emits the exact diagnostic:

void *msl = dlopen(
    "/System/Library/PrivateFrameworks/MallocStackLogging.framework/MallocStackLogging",
    RTLD_NOW);
void (*handle_memory_event)(unsigned long) =
    dlsym(msl, "msl_handle_memory_event");
handle_memory_event(0x80000000UL);

repro(<pid>) MallocStackLogging: can't turn off malloc stack logging because it was not enabled.

I injected that same callback after startup into each published Copilot TUI package listed above (using its matching app.js and native modules under an injectable Node host). Every version wrote one diagnostic directly into the alternate-screen UI.

I also scanned the signed launcher and matching native modules for every tested version:

turn_off_stack_logging imports:       0
turn_off_stack_logging lookup strings: 0

The MallocStackLogging strings inside runtime.node are environment-variable names; the diagnostic text and turn_off_stack_logging symbol/name are absent. I therefore could not substantiate the direct native-addon call asserted in #4375.

Conclusion

The underlying diagnostic is emitted by macOS when an MSL-disable memory-status event reaches a process where MSL was not enabled. The Copilot-specific bug is that an asynchronous native write to file descriptor 2 escapes into and corrupts the TUI. This also explains reports from unrelated long-running processes such as Ruby, Codex, and k9s.

A robust CLI-side fix would route process-level stderr through the logger/TUI renderer (or narrowly suppress this known harmless diagnostic) so asynchronous native diagnostics cannot draw directly into the alternate screen.

Environment: macOS 15.7.4 (24G517), arm64, iTerm2 3.6.11; MallocStackLogging, MallocStackLoggingNoCompact, MallocNanoZone, and DYLD_INSERT_LIBRARIES all unset in the natural occurrence.