fix(subprocess): make the Windows worker log handle inheritable

[mlandolfi90]

Problem

On Windows the supervised index worker's log file is always empty (0 bytes), so any worker failure is undiagnosable and the caller only ever sees the generic "Indexing worker crashed on a file" hint.

src/foundation/subprocess.c sets STARTF_USESTDHANDLES and calls CreateProcessW(..., bInheritHandles = TRUE, ...), but the log handle itself is created with lpSecurityAttributes = NULL:

hlog = CreateFileA(opts->log_file, GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS,
                   FILE_ATTRIBUTE_NORMAL, NULL);

A non-inheritable hStdOutput/hStdError leaves the child's stdio invalid, so every line the worker writes is discarded. The file is created (CREATE_ALWAYS) but stays 0 bytes.

This is the Windows half of the blind spot the reap-site comment in index_supervisor.c already describes:

Previously the log was ALWAYS deleted and only outcome+signal were logged, so a worker that exited non-zero left nothing to diagnose — the CI blind spot that hid this bug (a mangled JSON arg → "repo_path is required" exit) behind a generic "crashed on a file".

The log is now kept on failure, but on Windows it is empty, so the blind spot is still there.

Repro

Windows 11, reproduced on the released v0.9.0 binary and on current main (7d6cdb2).

bad.json — valid JSON, unknown key:

{"path":"C:\\some\\repo"}

codebase-memory-mcp cli index_repository --args-file bad.json

Result:

{"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 <CBM_CACHE_DIR>/logs/.worker-*.log → 0 bytes.

The worker did report the real cause. It was thrown away.

Fix

Open the log with an inheritable handle (SECURITY_ATTRIBUTES.bInheritHandle = TRUE), which is what STARTF_USESTDHANDLES + bInheritHandles = TRUE require.

Verification

Cross-compiled with llvm-mingw via test-infrastructure/docker-compose.yml (build-windows), run natively on Windows 11 — same command, same machine, same cache dir:

	worker log
before	0 bytes
after	346 bytes, containing repo_path is required

Full log contents after the fix:

level=info msg=mem.init budget_mb=11401 total_ram_mb=32574 source=ram_fraction
warning: passing raw JSON to 'cli index_repository' is deprecated and will be removed in a future release; use flags (run 'cli index_repository --help'), --args-file <path>, or piped stdin.
repo_path is required
level=info msg=index.worker.fast_exit action=_Exit

This restores the post-mortem for every supervised worker failure on Windows, not just this one — several open Windows reports of "worker crashed" with no further detail are likely the same missing diagnostic.

Not fixed here

The user-facing hint still says "Indexing worker crashed on a file" for every non-zero worker exit, which is misleading when the worker exited for a reason it reported explicitly. Happy to follow up in a separate PR if you want that reworded or made conditional.

🤖 Generated with Claude Code

[DeusData]

Thanks, and sorry for the delayed first response. Queued for review.

A nine-line change to make the Windows worker log handle inheritable is a good ratio of blast radius to value. CI is green; the branch is CONFLICTING against main, so it needs a rebase before I read it.

Windows handle-inheritance behaviour is genuinely hard to get right, and log capture on that path has been a recurring pain point, so this is welcome.

[DeusData]

Thank you for this, and I am sorry it sat long enough to be overtaken.

Your diagnosis was correct for the code you were looking at, and you did the right thing by reproducing it against the actual v0.9.0 release binary rather than a local build. The blind spot was real: on Windows the worker log handle was not inheritable, so worker logs came back empty exactly when someone needed them.

It has since been fixed on main, though not by a patch to cbm_run_win — the daemon rework in 0baddf7 replaced that path entirely. Current main opens the log via CreateFileW with SECURITY_ATTRIBUTES{ .bInheritHandle = TRUE } and scopes the inheritance with PROC_THREAD_ATTRIBUTE_HANDLE_LIST, so the handle reaches the intended child and only that child. That last part makes it strictly stronger than a plain inheritable handle, which would also leak into any other process spawned concurrently. The function your patch targets no longer exists, so the PR now shows as conflicting.

Closing as already fixed — with genuine thanks. Your reproduction is still useful to us: it is a ready-made check that current main writes non-empty worker logs on Windows, and I would welcome a shout if you ever see it come back.