Repository navigation
Windows dot imagegen with readable reference images immediately fails: AbsolutePathBuf deserialized without a base path #50170
Description
Environment
- Windows desktop app, version
26.928.4866.0(earlier tested version26.928.3736.0) - Pro account; dot with a connected Windows computer
- Latest retest: 2026-10-02, Asia/Jakarta (UTC+7)
- Full computer restart did not resolve the issue
Steps to reproduce
- In a dot execution task connected to Windows, use four existing, readable reference images.
- Supply their Windows absolute paths via
referenced_image_pathsto imagegen. - Invoke image generation with the existing prompt.
- Retest with ASCII-only filenames and paths, then after a full computer restart.
Example path shapes (user-specific directories redacted):
D:\yuanxing\Oyen.png
D:\yuanxing\Bimo.png
C:\Users\<user>\AppData\Local\Temp\kerupuk_refs_ascii_20261001_r1\SateWardrobe.jpg
C:\Users\<user>\AppData\Local\Temp\kerupuk_refs_ascii_20261001_r1\KerupukCompare.png
Actual result
Immediate failure:
AbsolutePathBuf deserialized without a base path at line 1 column 2397
An earlier invocation reported column 2539. No generation task ID or image was returned.
Latest post-restart invocation: 2026-10-02 03:49:08.335 UTC / 10:49:08.335 Asia/Jakarta. Same frozen prompt; all four files existed and hashes matched the preceding test. ASCII-only reference paths did not resolve it. This was one invocation, not a repeated generation loop.
Expected result
Readable Windows absolute reference paths should be accepted and correctly resolved for image generation.
Scope
A successful prior reference-image workflow was reported, but its exact historical tool arguments have not been recovered. An update regression is therefore a hypothesis, not a confirmed cause. No base-path argument is exposed in the observed generation interface.
Related reports, not confirmed duplicates
- [Windows] image_gen hangs indefinitely when any reference image is supplied #40233: same reference-image generation operation, but hangs rather than this immediate error.
- Windows desktop: local image/file previews hang with fs/readFile AbsolutePathBuf error #49891: same core AbsolutePathBuf error on valid Windows PNGs, but file preview/read operation.
Please investigate Windows path serialization/interpretation at the generation boundary and provide safe diagnostics that preserve existing tasks and assets.
Activity
psychodissection-ship-it commentedon Oct 2, 2026
Additional matching Windows Work reproduction
Observed on 2026-10-03 using a connected native Windows executor. Bundled Codex CLI: 0.159.0-alpha.12.1; OS: Windows 11 build 26220.
A local PNG reference was acquired successfully with the ordinary attachment download tool and opened successfully with view_image. The file existed and was readable in the actual Work context. Passing its native Windows absolute path via referenced_image_paths to image_gen failed immediately:
No generation was completed by that failed attempt. Re-displaying the same reference and using the supported recent-conversation-image route then completed one image successfully. The existing returned PNG Base64 data was saved to the local project, and file existence, decoding, and visual display were verified. No substitute reference or reference-free generation was used.
This comparison separates reference-file access from the generation path parser: the same intended reference was accessible, and generation worked through the conversation-image route. The service-side Windows path parser itself remains unresolved. It does not prove a particular conversion bug or a version regression.
Please investigate host-aware reference-path handling at the Windows-to-generation boundary, and clarify the supported way to transfer an already-readable Windows reference image when referenced_image_paths fails here.
No usernames, project paths, project source text, reference assets, generated artwork, credentials, or signed download URLs are included in this report.
WESLEY780 commentedon Oct 3, 2026
@psychodissection-ship-it Thanks for the matching report. Could you return all three outcomes below from your own Windows desktop/dot setup? Our comparison build is Codex app 26.930.31730, build 12947, Windows package 26.930.3930.0, bundled CLI 0.160.0. Different versions are useful too, but please label them; no update or configuration change is requested.
Could you try these three independent checks in your own account and share sanitized outcomes for all three? You can paste this comment into your own dot and request “Run T1”, “Run T2”, “Run T3”, or “Run all three.” If one is blocked, please continue the others. This invitation does not itself authorize access or image generation; the account owner must supply their own inputs and explicitly approve T2.
Report each as PASS / FAIL / BLOCKED / NOT_RUN. Include current UTC timestamp, Codex app version, Windows build, CLI version where applicable, actual task origin (ordinary local Windows versus dot-created connected Windows executor), available relevant tools, concrete actions and returned evidence, and exact sanitized errors. Mark unknown versions honestly. PASS requires observed results; missing inputs/tools/permission mean BLOCKED; an attempted supported operation failing its criterion means FAIL. Unselected tests are NOT_RUN. Do not infer other-platform results.
T1 — Uploaded PNG viewing
Attach your own innocuous, distinctive PNG. Ask the agent to identify two specific visual details without revealing them beforehand. It must distinguish actual inline pixels from a documented official attachment-materialization route followed by native viewing, such as Library materialization when available. Metadata, filenames, dimensions, and IDs do not count as seeing the image. Record which route actually rendered pixels. If generic download_file fails, report that error separately; it does not establish that every official route fails. Do not assume one tool is universally the intended route. No custom uploader, guessed URLs, or permission bypass. A documented permitted fallback can pass its own route but cannot prove the direct route is fixed. Stop denied routes.
T2 — Windows local-reference image generation
In the intended already-existing Windows task, provide an exact path to your own innocuous PNG inside its allowed filesystem scope. Explicitly authorize using that file for one generation. First verify executor, file existence/readability, and native image viewing; note two distinctive input details. Missing access, viewing, or native image-generation capability means BLOCKED. For dot, use the supported route to an already-existing, owner-authorized connected Windows task and report that route. If none is available, mark BLOCKED. Do not create tasks or switch environments to get around a denial.
Inspect the current native imagegen contract. Use referenced_image_paths for the verified PNG when supported; if all references have local paths, do not use recent-image fallback or num_last_images_to_include. Generate: “Preserve this image's distinctive subject, colors, and arrangement; add a thin blue border.” Maximum ONE generation invocation across the entire protocol, reruns, and environment comparisons unless the owner renews authorization. Never retry an uncertain submission. Record no job / job created / unknown from actual evidence. Inspect the real output for reference incorporation and the edit; a job ID alone is insufficient. Distinguish preflight, submission, and output failures. The procedure applies separately to ordinary local Windows and dot-created connected Windows tasks; do not automatically run two paid comparisons.
T3 — Existing local-thread read
Provide the exact ID of your own existing local thread and authorize reading it. Use only a supported official read interface actually exposed in this task; otherwise mark BLOCKED. Attempt one read with the ID unchanged. PASS requires returned target messages, not an existence check. Report exact sanitized errors. Do not send to any thread, alter IDs, use private RPCs, inspect database/transcript files, or bypass denials. An optional read-only control against an already-known, authorized direct child must be reported separately; it cannot establish success for the target. Do not create a control thread.
Return results privately to the owner, who chooses what to share here. No monitoring or automatic posting. Redact usernames, paths, thread/file IDs, private text, credentials, and other identifying error values while preserving error wording. Do not upload images, attachments, or logs externally without owner permission. Missing prerequisites stop only the affected test; request the missing input and report the other outcomes.
Copyable result template (return all three rows, including blocked/unselected ones):
Environment: UTC / app+build / Windows build / bundled CLI / verified versus owner-reported / task origin.
T1: status; actual image access route; two visual observations; sanitized exact error or none.
T2: status; calling task type; preflight; invocation count; no job/job/unknown; output visually verified; sanitized exact error or none.
T3: status; official interface; actual target contents returned yes/no; sanitized exact error or none; separate control outcome if tested.
No common root cause is assumed among these three checks.
JF10R commentedon Oct 7, 2026
I tested the three diagnostics on October 6, 2026. Results:
T1 — PASS through Library materialization and native image viewing. An existing PNG attachment was retrieved and visually inspected. The initial download_file attempt failed with “file could not be authorized or resolved”; Library materialization succeeded. This was an existing attachment, not a fresh blind recognition test, and does not establish inline attachment rendering.
T2 — FAIL at 21:06:22 UTC in the existing Windows task. The local PNG was readable and inspected visually before calling imagegen. It showed a three-view creature sheet with bark, moss, stones and blue mushrooms. We used referenced_image_paths and the exact prompt: “Preserve this image's distinctive subject, colors, and arrangement; add a thin blue border.”
One invocation, no retry within this diagnostic. Immediate error: “AbsolutePathBuf deserialized without a base path at line 1 column 250”. No image or job identifier returned; server-side job creation is unknown. Two earlier production attempts, outside this diagnostic, also failed with Windows backslash and forward-slash paths.
T3 — PASS at 21:05:18 UTC through the supported local read_thread tool: an actual message from the requested existing thread was returned. Separately, reading that same thread from the parent dot failed with “unsupported placement format version 2”.
Windows build: 26300.9550. Installed CLI: 0.117.0; this is not verified as the desktop-bundled runtime. Desktop app version and imagegen backend version remain unknown. No configuration changes were made.
These results isolate a reproducible failure at the Windows imagegen reference-path boundary; they do not establish its root cause.
Follow-up: another existing local Codex task successfully generated all six requested images using local reference paths. The files were saved and visually verified. The dot-created task’s AbsolutePathBuf failure remains unresolved. This provides a working execution route in our setup, but does not establish which difference between the tasks causes the failure.
Update — October 7, 2026, approximately 16:05 UTC: after updating codex-cli locally, I requested the same diagnostics again. T1 still passes via Library materialization and native viewing of the existing attachment. T2 is BLOCKED, not a reproduced imagegen failure: resuming the existing Windows task and listing available environments both now return “RuntimeError: The invoking thread is not attached to an active Aeon”. Consequently, the new installed CLI version and the desktop-bundled runtime could not be verified, and no new imagegen invocation was made. The local T3 route also could not be reached; a separate parent-side read of the same existing local thread still fails with “unsupported placement format version 2”. This does not establish whether the CLI update fixed the original imagegen error; it records the separate task-access blocker preventing that retest.
Update — October 7, 2026, after using dot > Reboot (approximately 17:34–17:44 UTC): computer discovery and resuming the existing connected Windows task now succeed, and actual Windows shell commands execute. The previous “The invoking thread is not attached to an active Aeon” blocker no longer prevents those operations. This tests discovery and existing-task resumption, not new-task creation or Chrome access.
T1 — PASS again via Library materialization and native viewing of the same known PNG. This remains a known-reference test, not a fresh blind test or evidence of inline rendering.
T2 — FAIL, now actually retested. At 17:39:19 UTC, one imagegen invocation with the same verified local PNG, referenced_image_paths, and the same thin-blue-border prompt returned the identical error: “AbsolutePathBuf deserialized without a base path at line 1 column 250”. The reference was checked visually and by hash. No output image was returned; backend job creation remains unknown. No retry was made.
T3 — BLOCKED in the Windows task: read_thread is not exposed in its current tool set, so no local read invocation was possible. Separately, the parent-side official read still returns “unsupported placement format version 2”. Tool absence is distinct from reproducing that error locally.
Versions now verified by the Windows task: standalone CLI found is still 0.117.0; the application-bundled CLI used by the application is 0.160.1; application package 26.930.7945.0; Windows build 26300.9550 / 26H2. No configuration changes or game launches were performed during these diagnostics. In this session, reboot restored Windows task execution but did not resolve the imagegen reference-path failure.
ve6btc commentedon Oct 7, 2026
For the exact
The invoking thread is not attached to an active Aeonblocker reported in this comment: clicking my dot's name in the upper-left corner, then Reboot, restored computer discovery, new task creation, and Chrome access on Windows 26.1002.52244 today (October 7).At that check, local commands still failed with
helper_unknown_error: setup refresh had errors. This workaround is confirmed in my session; I haven't verified any fix for imagegen's AbsolutePathBuf error. Full results.Update, October 7, after 18:48 UTC: following my reported Windows x64 rollback, an existing dot-created task successfully ran
Get-Location, a directory listing, andgit --version; the setup-refresh error was absent. The installed app version was not independently read. Full verification, limitations, and the official-hosted rollback package. This Windows-only community workaround does not establish recovery of other symptoms in this thread. Back up local data before a rollback; the newer update may be offered again.