Codexify 2.3.24: exact 1 MiB PowerShell reproducer still stops the native Windows service on affected Windows 10 machine #15

Activity

1. Snk-knS commented on Oct 30, 2026

   

   Snk-knS

   on Oct 30, 2026

   Last edited by Snk-knS

   Author

   More actions

   Well, I guess this means no Codexify for me... :(
   I'm sure it's probably me not being able to make it work (skill issue).
   Some things just aren't meant to be, I guess...

   AI:

   Windows environment:

   1. Edition: ProfessionalEducation
   2. DisplayVersion: 22H2
   3. Build: 19045
   4. UBR/update revision: 6332
   5. Architecture: AMD64 / x64

   One more 2.3.24 incident happened during normal project setup, before I could start using the Python/C# execution route on a real workload.

   Important clarification: this was not a first test of whether Python/C# was safe.

   I had already done separate controlled testing of the Python/C# route, and it appeared safe enough to use as the workaround path. The intended execution model for this project was:

   Codexify structured tools -> shared Python helper -> external executable via Python with shell=False -> PowerShell only when genuinely required

   What I wanted to do now was use that previously tested route on a real project and observe how it behaved in normal work.

   I never got that far.

   The main difference in this incident was that the new project was intended to live on D: instead of my usual C: Codexify workspace:

   D:\codexify\.Project\JNightmare

   Codexify was currently advertising its access root as:

   C:\Users\EDU\Codexify

   The agent noticed that the requested D: root was outside the advertised access root and correctly refused to substitute another workspace or write elsewhere.

   Before I could expose/register the intended project, and before any live Python/C# workload was executed, Codexify stopped/crashed. The Browser Companion stopped as well.

   Post-crash state:

   • Codexify service stopped
   • Installed: yes
   • Enabled: yes
   • state=Ready
   • local health unreachable
   • Browser Companion stopped

   The Codexify log also appears to end during the new project/window setup and project-listing activity.

   I am not claiming that the D: drive or the out-of-access-root path caused the crash. It is simply the notable difference in this incident.

   The key point is that the already-tested Python/C# workaround route was never reached: Codexify stopped earlier, during setup.

   Codexify-2.3.24-D-drive-project-crash-before-live-python-route.md
   codexify-2.3.24-new-window-path-crash.zip
2. Snk-knS commented on Oct 30, 2026

   

   Snk-knS

   on Oct 30, 2026

   Last edited by Snk-knS

   Author

   More actions

   Follow-up: I have not been able to reproduce this crash again so far.

   I repeated the same general setup flow several times, including the project listing and the D: project-root path scenario, while monitoring the Codexify-related processes externally.

   So far, the later attempts have remained stable and I have not observed the same Codexify + Browser Companion shutdown again.

   At this point, the crash does not appear to be deterministically reproducible from the setup steps alone.

   EDIT:

   One additional detail: during the original crash, another Codexify conversation was actively doing unrelated maintenance work involving the same project/runtime area, including file migration and PowerShell/Python checks.

   That conversation was left hanging when Codexify crashed. On later non-reproducing tests, I had not re-triggered it, so I cannot assume the same concurrent workload was still active.

   This does not prove concurrency caused the crash, but it remains a possible timing factor. So far, I still cannot reproduce the shutdown deterministically.
3. Snk-knS commented on Nov 1, 2026

   

   Snk-knS

   on Nov 1, 2026

   Author

   More actions

   Follow-up: Python/C# workaround was incomplete; PowerShell 7.6.9 passes controlled differential tests

   Hey Devnoname! I have an update on this situation. :)

   The initial mitigation used a Python-first execution path, subprocess(..., shell=False), and C#/.NET where useful, with shell use reduced as much as possible. In a real Codexify Goal, however, this did not fully solve the problem: exec_command still remained in the orchestration path, and Windows PowerShell 5.1 could not be completely excluded from the workflow. The project eventually reproduced the same crash class despite the workaround.

   After that, I ran a separate controlled comparison using portable PowerShell 7.6.9. These were laboratory-style tests, not yet a full real-world Goal run. The same historical 1 MiB typed-array reproducer passed repeatedly through several PowerShell 7.6.9 launch routes, including Python and C# child-process wrappers, repeated lifecycle tests, and heavier mixed workloads.

   As a control, the same reproducer was then executed through the normal Windows PowerShell 5.1 route. Codexify crashed, Browser Companion went down with it, and after restart the pending execution appeared to resume/replay and triggered a second crash. I am treating the replay mechanism as an observation/inference, not as a proven internal cause.

   There was also a separate recurring issue where the coordinator became stuck in repeated turn_completed timeout cycles after work had already finished. That appears distinct from the PowerShell workload crash, but it is worth mentioning because from the UI it looks like Codexify has gone offline or stalled.

   So the current picture is:

   the original Python/C# workaround reduced risk but did not fully remove the unstable execution path in real Goal work;
   portable PowerShell 7.6.9 has performed very well in controlled stress/differential testing;
   Windows PowerShell 5.1 remains the strongest crash correlate so far;
   PowerShell 7.6.9 has not yet been validated in a full real project Goal, only in controlled tests.
   I have attached the detailed reports with the exact routes, stress counts, lifecycle observations, and limitations.

   POWERSHELL_7_6_9_STRESS_REPORT.md
   RESULTS.md
   FINAL_EXECUTION_ROUTE_DIFFERENTIAL_AND_WINDOWS_POWERSHELL_5_1_CRASH_REPLAY_REPORT.md
4. Snk-knS commented on Nov 3, 2026

   

   Snk-knS

   on Nov 3, 2026

   Author

   More actions

   Small update after a full day of controlled testing:

   I ran an active goal under a strict execution protocol: "exec_command" was allowed to use only portable PowerShell 7.6.9 ("pwsh"), together with Codexify's normal built-in tools. I intentionally did not use Python or C#.

   During the whole test period I did not reproduce the previous "exec_command" crash. So far, using PowerShell 7 instead of Windows PowerShell 5.1 appears to be a viable workaround on this machine.

   The only recurring anomaly was unrelated to command execution: during longer-running goals, ChatGPT/Browser Companion would sometimes show "Message delivery timed out", the Codexify chat would switch to "offline", and visible goal progress would stop.

   I have not yet tested simply leaving it untouched in that state to see whether Codexify's automatic goal recovery resumes it. I will try that next.

   So at this point:

   • Windows PowerShell 5.1 path: previously reproducible crashes
   • portable PowerShell 7.6.9 path: no "exec_command" crash during a full day of goal execution
   • occasional Browser Companion / message-delivery timeout and offline transitions still occur.
5. Snk-knS commented on Nov 4, 2026

   

   Snk-knS

   on Nov 4, 2026

   Author

   More actions

   Small correction to my previous update: you had already warned me that local service/tunnel recovery is separate from agent-session recovery, and that automatic wake-up/continuation requires the corresponding ChatGPT conversation to be explicitly paired.

   I had forgotten that distinction, so I was treating some of the offline cases as a separate failure when the missing pairing could already explain them.

   However, there is still one issue after correcting that: pairing now completes successfully, but the paired ChatGPT conversation still does not regain ownership of the Codexify task or file/tool access.

   The task state shows schemaRolloverPending: true (generation: 1, verifiedOwnerGeneration: 0), and the previous schema refresh is still recorded as failed.

   So the page can be verified as paired, but it still ends up read-only / told to continue in a new conversation instead of becoming the active agent for the task.
6. Snk-knS commented on Nov 4, 2026

   

   Snk-knS

   on Nov 4, 2026

   Author

   More actions

   One more data point after my last update:

   I tested the normal standalone New chat handoff flow.

   On another PC running the same Codexify version, it works correctly: the new ChatGPT conversation is created, ownership transfers, and the task continues from where it left off.

   On the affected laptop, the same flow only reaches Retry creation. Pressing Retry creation returns almost immediately to the same state and the Browser Companion does not complete the ChatGPT-side handoff.

   I also tried creating a fresh ChatGPT conversation manually and pairing it to the task. Pairing verifies successfully and Codexify recognizes the correct project, but the new conversation still immediately gets the same “task transferred to a new conversation / new owner” state and has no functional task/file access.

   So this now looks more specifically like the one-time continuation/ownership handoff is failing on this laptop, while pairing verification itself succeeds.
7. devnoname120 commented on Nov 10, 2026

   

   devnoname120

   on Nov 10, 2026

   Owner

   More actions

   I investigated this against current main and opened #17 with a fix.

   The evidence supports a narrower failure boundary than “the 1 MiB buffer crashes Codexify” or a proven Rust panic:

   • v2.3.24 already launched workers with CREATE_NO_WINDOW, drained their output asynchronously, and contained them in a Job Object;
   • the audit/log stream ends after worker spawn, without a Rust panic, normal return, or shutdown marker;
   • the same workload and heavier variants pass through PowerShell 7, cmd.exe, Python, and C# routes, while Windows PowerShell 5.1 remains the repeatable crash correlate on the affected machine;
   • the Scheduled Task itself also stopped, so keeping a persistent PowerShell process as the service root left the whole service inside the same demonstrated failure domain.

   PR #17 therefore removes both legacy-PowerShell dependencies from the default path:

   1. Implicit/model-selected Windows command execution now prefers PowerShell 7 and otherwise falls back to cmd.exe; it never implicitly selects Windows PowerShell 5.1.
   2. An explicit pwsh request is strict and cannot silently downgrade to powershell.exe. An explicit generic powershell request retains the old compatibility fallback only when PowerShell 7 is unavailable.
   3. The persistent PowerShell Scheduled Task launcher is replaced by a hidden native codexify service launch --scheduled-task supervisor. It captures output, applies bounded restart backoff, and contains the supervisor tree in a kill-on-close Job Object; the existing service supervisor separately contains the server tree.
   4. Exact recognized legacy task actions are migrated with bounded reads and compare-and-swap updates. Modified or custom task actions are left untouched.

   Verification is complete on commit 4108d02:

   • cargo fmt --all --check
   • cargo clippy --all-targets --all-features -- -D warnings
   • cargo test --all-targets --all-features -- --test-threads=1
   • all four CI jobs passed, including the windows-latest service and self-update integration suite

   The exact external mechanism terminating Windows PowerShell 5.1 on this particular machine is still not proven. The fix is intentionally based on the reproducible boundary: it removes Windows PowerShell 5.1 and a persistent PowerShell task root from Codexify's implicit/default service path rather than claiming an undocumented PowerShell, endpoint-security, or buffer-management defect.

   The later schemaRolloverPending / continuation-ownership reports are a separate path; current-main continuation, pairing, rollover, and renewal tests remain green, so I have not folded those symptoms into this fix. Likewise, the 2.3.23 → 2.3.24 updater-status observation began under the old 2.3.23 worker and does not isolate current updater behavior.

   #17 contains Fixes #15, so this issue will close when the PR is merged. After the corresponding release, the useful final validation is to rerun the original workload through Codexify's default execution path on the affected Windows 10 machine and report whether the service and Browser Companion remain healthy.

   ❤️React with ❤️1Reacted by Snk-knS