Summary
I found several issues when using Graphify on Windows with a Spring Boot / Java project (with both src/main and src/test) after running graphify codex install.
The current rebuild/update flow is not stable in this setup.
Issues observed
-
python3 in AGENTS.md is unreliable on Windows
The generated command uses:
python3 -c "from graphify.watch import _rebuild_code; from pathlib import Path; _rebuild_code(Path('.'))"
On my machine, python3 points to the WindowsApps stub launcher, exits with code 1, and produces no useful error output.
-
Wrong output/cache root for Java project layout
In a Spring Boot project with both src/main and src/test, _rebuild_code(Path('.')) may infer the wrong root and generate graphify-out inside a nested package path such as:
src/main/java/com/nsoc/graphify-out
instead of the repository root:
-
Cache replace can fail with WinError 5
The cache write path uses temp file -> os.replace(). On Windows this can fail with WinError 5, causing rebuild failure.
-
Failure is silent when _rebuild_code() returns False
The generated command does not convert a False return value into a non-zero exit code, so Codex may think rebuild succeeded even when it failed.
Why this matters
These issues make Graphify/Codex integration unreliable on Windows:
- rebuild may not run
- output may be written to the wrong directory
- rebuild may fail due to Windows file locking behavior
- failure may still look like success
This can leave Codex working against stale or broken graphify-out data.
Suggested fixes
- Use a Windows-safe Python invocation for Codex integration (
py -3, python, or a generated wrapper script)
- Keep rebuild output anchored to the repository root
- Make cache writes more robust on Windows (
PermissionError retry/fallback)
- Exit non-zero when
_rebuild_code() fails
Environment
- OS: Windows
- Project type: Spring Boot / Java
- Layout includes:
src/main/java/...
src/test/java/...
Summary
I found several issues when using Graphify on Windows with a Spring Boot / Java project (with both
src/mainandsrc/test) after runninggraphify codex install.The current rebuild/update flow is not stable in this setup.
Issues observed
python3inAGENTS.mdis unreliable on WindowsThe generated command uses:
python3 -c "from graphify.watch import _rebuild_code; from pathlib import Path; _rebuild_code(Path('.'))"On my machine,
python3points to the WindowsApps stub launcher, exits with code 1, and produces no useful error output.Wrong output/cache root for Java project layout
In a Spring Boot project with both
src/mainandsrc/test,_rebuild_code(Path('.'))may infer the wrong root and generategraphify-outinside a nested package path such as:instead of the repository root:
Cache replace can fail with
WinError 5The cache write path uses temp file ->
os.replace(). On Windows this can fail withWinError 5, causing rebuild failure.Failure is silent when
_rebuild_code()returnsFalseThe generated command does not convert a
Falsereturn value into a non-zero exit code, so Codex may think rebuild succeeded even when it failed.Why this matters
These issues make Graphify/Codex integration unreliable on Windows:
This can leave Codex working against stale or broken
graphify-outdata.Suggested fixes
py -3,python, or a generated wrapper script)PermissionErrorretry/fallback)_rebuild_code()failsEnvironment
src/main/java/...src/test/java/...