Skip to content

fix(server): stop tying codex text-generation temp files to the caller's scope - #5406

Merged
juliusmarminge merged 2 commits into
t3code/codex-turn-mappingfrom
t3code/codex-textgen-temp-scope
Aug 5, 2026
Merged

fix(server): stop tying codex text-generation temp files to the caller's scope#5406
juliusmarminge merged 2 commits into
t3code/codex-turn-mappingfrom
t3code/codex-textgen-temp-scope

fix(server): clean up codex temp directories when allocation fails pa…

0a5b8c1
Select commit
Loading
Failed to load commit list.
MacroscopeApp / Macroscope - Effect Service Conventions succeeded Aug 5, 2026 in 44s

Effect Service Conventions: All clear

All clear

Details

Note

Your check run agent prompt is: .macroscope/check-run-agents/effect-service-conventions.md
More information about how Check Run Agents work can be found in our Help Center.


🔍 Agent activity — reasoning, no tool calls

💭 I'm reviewing the changes to CodexTextGeneration.ts to see how the scoped temp file usage was removed. I'm checking whether this change aligns with the existing conventions around error handling and file operations. The scope here is about temporary files rather than the broader patterns already established for imports, service definitions, and error formatting. The error structure with detail attributes is already in place, so I'm mainly verifying that the new temp file handling follows the same conventions. Looking at the temp file cleanup logic — removeTempFileDir deletes the parent directory recursively, which makes sense since makeTempFile creates a fresh temp directory containing the file. The test properly creates and closes a Scope, and the focused test is justified since this is a behavior change rather than just a refactor. The error handling in writeTempFile with cleanup inside the error handler looks correct. Now I'm checking the imports — the test uses consistent patterns with the existing codebase, pulling from "effect/vitest" and "vite-plus/test". The touched code doesn't consolidate named imports from "effect" root in a way that violates conventions, and I'm verifying that Effect.catch and the Effect.onError cleanup pattern are both valid. The temp file handling looks solid — Effect.ensuring covers interruption in the main flow, and Effect.onError in Effect 4 handles failures and interrupts through the Cause type. This passes the check, so the response is success with "All clear".


Agent Credits: 27 credits