Environment
- graphifyy 0.9.39, macOS 15, Claude Code host with tool-permission gating
What happens
Step 9's cleanup is the only part of the pipeline that shells out instead of using Python:
rm -f graphify-out/.graphify_detect.json graphify-out/.graphify_extract.json ...
find graphify-out -maxdepth 1 -name '.graphify_chunk_*.json' -delete 2>/dev/null
rm -f graphify-out/.needs_update 2>/dev/null || true
In a host where the agent's shell commands are permission-gated, rm and find -delete are commonly not on the allowlist — destructive filesystem verbs are exactly what such policies withhold. Both calls were denied in my run, the pipeline had no fallback, and the intermediates stayed on disk:
1.5M .graphify_extract.json
1.4M .graphify_ast.json
87K .graphify_analysis.json
74K .graphify_semantic.json
74K .graphify_semantic_new.json
63K .graphify_chunk_01.json
10K .graphify_detect.json
~3 MB of intermediates per run, and .graphify_semantic_new.json / .graphify_chunk_*.json are exactly the files Step B3 and Part C read unconditionally — so a later --update can merge a stale chunk from a previous run rather than a fresh one.
Why this variant is new
Closed #1172 (fish/zsh glob on pure-code corpora) and closed #464 (Codex/Windows leftovers) are the same symptom from shell-dialect causes. This one is a permission policy, so it reproduces on any host that gates destructive shell verbs regardless of platform or shell — and unlike a glob mismatch, retrying or changing shell does not help.
Suggested fix
Do the cleanup in Python like every other step, e.g. Path.unlink(missing_ok=True) in a loop plus Path.glob('.graphify_chunk_*.json'). That removes the shell dependency entirely, works identically on Windows/POSIX, and sidesteps all three reported causes at once. If the shell form is kept for any reason, at minimum the pipeline should verify the files are gone and warn rather than assume success, since a surviving .graphify_chunk_*.json is a correctness risk, not just clutter.
Environment
What happens
Step 9's cleanup is the only part of the pipeline that shells out instead of using Python:
In a host where the agent's shell commands are permission-gated,
rmandfind -deleteare commonly not on the allowlist — destructive filesystem verbs are exactly what such policies withhold. Both calls were denied in my run, the pipeline had no fallback, and the intermediates stayed on disk:~3 MB of intermediates per run, and
.graphify_semantic_new.json/.graphify_chunk_*.jsonare exactly the files Step B3 and Part C read unconditionally — so a later--updatecan merge a stale chunk from a previous run rather than a fresh one.Why this variant is new
Closed #1172 (fish/zsh glob on pure-code corpora) and closed #464 (Codex/Windows leftovers) are the same symptom from shell-dialect causes. This one is a permission policy, so it reproduces on any host that gates destructive shell verbs regardless of platform or shell — and unlike a glob mismatch, retrying or changing shell does not help.
Suggested fix
Do the cleanup in Python like every other step, e.g.
Path.unlink(missing_ok=True)in a loop plusPath.glob('.graphify_chunk_*.json'). That removes the shell dependency entirely, works identically on Windows/POSIX, and sidesteps all three reported causes at once. If the shell form is kept for any reason, at minimum the pipeline should verify the files are gone and warn rather than assume success, since a surviving.graphify_chunk_*.jsonis a correctness risk, not just clutter.