Index Error: outcome=killed exit_code=-1 signal=9

Version

codebase-memory-mcp 0.9.0

Platform

Linux (arm64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

codebase-memory-mcp-linux-arm64-portable-0.9.0.tar.gz

codebase-memory-mcp cli index_repository --repo-path /path/to/my/code
level=info msg=mem.init budge_mb=1989 total_ram_mb=7957
level=info msg=index.supervisor.reap outcome=killed exit_code=-1 signal=9
level=info msg=index.supervisor.workder_failed outcome=killed exit_code=-1 log=~/.cache/codebase-memory-mcp/logs/.worker-13534.log
level=info msg=index.supervisor.reap outcome=killed exit_code=-1 signal=9
level=info msg=index.supervisor.workder_failed outcome=killed exit_code=-1 log=~/.cache/codebase-memory-mcp/logs/.worker-13534.log
{"status":"error","outcome":"killed","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file.","repo_path":"/home/admin/Work/dev/code"}

Reproduction

codebase-memory-mcp cli index_repository --repo-path /path/to/my/code
level=info msg=mem.init budge_mb=1989 total_ram_mb=7957
level=info msg=index.supervisor.reap outcome=killed exit_code=-1 signal=9
level=info msg=index.supervisor.workder_failed outcome=killed exit_code=-1 log=~/.cache/codebase-memory-mcp/logs/.worker-13534.log
level=info msg=index.supervisor.reap outcome=killed exit_code=-1 signal=9
level=info msg=index.supervisor.workder_failed outcome=killed exit_code=-1 log=~/.cache/codebase-memory-mcp/logs/.worker-13534.log
{"status":"error","outcome":"killed","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file.","repo_path":"/home/admin/Work/dev/code"}

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

I searched existing issues and this is not a duplicate.
My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

Possibly related data point, different platform: I hit the same index.supervisor.worker_failed message family on Windows (x64), v0.9.0, native binary, but with exit_code=1 (no signal) rather than signal=9, so it may or may not share the same root cause as the Linux/arm64 report above.

Upgraded a working v0.8.1 install to v0.9.0 (checksum + SLSA verified before swap).
A scheduled incremental reindex of a local mid-size repo (~4800 nodes / ~10700 edges at the 0.8.1 baseline) then failed 100% of the time — a scheduled task retried it every 20 minutes for ~30 hours straight, every single attempt failed the same way.
No culprit file was ever identified in the output.
The worker log referenced in the worker_failed message was empty (0 bytes) every time — no stack trace, nothing to point at a cause. That alone might be worth a look: crash logging doesn't seem to be capturing anything on this failure path, at least on Windows with exit_code=1.
Rolling back to v0.8.1 (same repo, same machine, only the binary changed) immediately restored successful reindexing (~0.3s, 4834 nodes, healthy).

I don't have a shareable minimal repro (private repo, and since the logs were empty I can't even point at which file triggers it), so I'm not filing a separate issue per the bug report template's requirement for shareable repro — just flagging in case the empty-log behavior or the Windows/exit_code=1 variant of this crash is useful signal for triage here. Happy to try anything diagnostic (e.g. CBM_DIAGNOSTICS=1) on request if it would help.

In my case, I got the same message in Windows:

{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}

And the problem was beause I was not escaping quotes in CMD. I solved it using:

codebase-memory-mcp cli index_repository "{"repo_path": "C:\Users\LENOVO\source\repos\Project"}"

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

Thanks for the report. This remains a high-priority 0.9.1-rc worker-crash issue. Please attach the referenced worker log, the exact Linux arm64 command or JSON argument form, repository file count and main languages, and whether the same path succeeds in fast mode. The Windows quoting workaround reported in the comments may be a separate invocation issue, so marking awaiting-reporter for the original Linux evidence.

Quick clarification to disambiguate my Windows report above from the CMD quoting workaround, since it was flagged as possibly a separate invocation issue.

My case can't be a quoting or argument-formatting problem. The failing call was an unattended, scheduled invocation whose argument string was byte-for-byte identical before and after the upgrade — the exact same command succeeded on 0.8.1 and then failed 100% of the time on 0.9.0, with only the binary swapped in between. If the argument were malformed, it would have failed on 0.8.1 too.

So on Windows x64 this looks like a genuine 0.8.1 → 0.9.0 regression on the incremental-reindex path, not a caller-side invocation error. Rolling the binary back to 0.8.1 (nothing else changed) immediately restored healthy reindexing.

The one thing I still can't provide is a shareable repro or a non-empty worker log — the referenced worker log was 0 bytes on every failure, so there is nothing on the Windows side to point at a culprit file. If it helps triage, I can test whether the same path also fails in fast mode, or run a diagnostic build / env flag on that empty-log path — happy to.

@DeusData

@DeusData
command:
codebase-memory-mcp cli index_repository --repo-path /home/admin/Work/credit-ucode
file count:

git ls-files | wc -l
46466

main language: Java8
Fast mode: Succeed
codebase-memory-mcp cli index_repository --repo-path /home/admin/Work/credit-ucode --mode fast
worker log:

Thanks for the version regression clarification, the 46,466-file Java scale, and the fast-mode control. That is enough to return the issue to the maintainer queue, so I removed awaiting-reporter. The evidence now points to a 0.9.0 non-fast indexing regression rather than shell quoting, while the empty worker-log failure remains linked to the broader diagnostic gap in #1132.

fix(index): make a crashed worker's log survive and name the run

@DeusData

@DeusData still not working for non-fast mode with 0.10.8

@lindeer

Thank you, @lindeer, for sticking with this and retesting on 0.10.8, and @MSV1971 and @JA-Developer for the extra data points! A signal=9 with an empty log, on an 8 GB machine, on a 46k-file Java repo, where fast mode succeeds, points strongly at the OS killing the worker for memory rather than a crash in one file. v0.11.0 reworked exactly this area. Allocation now goes through one memory core that respects the budget and spills to disk instead of growing, and we're finishing one more change for the phases after extraction.

Could you retest on v0.11.0 in the default mode? If it still fails, please paste these as text (screenshots are hard to search):

the full output;
the worker log it names;
the output of dmesg | grep -i -E 'oom|killed process', run right after the failure.

@MSV1971, a v0.11.0 retest of your scheduled reindex would tell us whether the Windows exit_code=1 / empty-log case is gone too; several Windows worker-recovery fixes have landed since 0.9.0. Thanks!

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Navigation Menu

Repository navigation

Index Error: outcome=killed exit_code=-1 signal=9 #1070

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Index Error: outcome=killed exit_code=-1 signal=9 #1070

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Activity

MSV1971 commented on Jul 13, 2026

JA-Developer commented on Jul 14, 2026

github-actions commented on Jul 14, 2026

DeusData commented on Jul 14, 2026

MSV1971 commented on Jul 17, 2026

lindeer commented on Jul 17, 2026

DeusData commented on Jul 18, 2026

lindeer commented on Sep 11, 2026

DeusData commented on Sep 25, 2026

github-actions commented on Sep 26, 2026

github-actions commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions