Fix Linux file manager target in worker registry

[ihipop]

Fixes #545.

Summary

• add a core extracted-app patch for .vite/build/worker.js
• inject the missing Linux fileManager target into the worker open-target registry
• add regression coverage for the direct worker patch and the patchExtractedApp path

Notes

The existing Linux file manager patch covers the main bundle, but current Codex.app builds also have a separate open-target registry in worker.js. That worker-side fileManager target only had darwin and win32, so Linux could still hit Unknown open target "fileManager" from the worker path.

Validation

node --test scripts/patch-linux-window-ui.test.js

Result: 292 passed, 0 failed.

[avifenesh]

This is an auto review done by revuto.

---

Reviewed the worker fileManager open-target patch. One issue worth confirming around the new descriptor's CI status semantics for the worker bundle; otherwise the patch logic mirrors the existing file-manager patch and is idempotent. Inline note below.

[MuQY1818]

It works on my Ubuntu 22.04

[avifenesh]

This is an auto review done by revuto.

---

Reviewed the worker fileManager open-target patch. The core logic is sound: applyLinuxWorkerFileManagerPatch reuses the established findCallBlock + }}); insertion approach, is idempotent (guarded by block.text.includes("linux:{")), and patchLinuxWorkerFileManagerTarget distinguishes the three cases (target missing, target present + already patched, target present + patch not applied) so upstream drift surfaces as skipped-optional rather than being silently swallowed. The descriptor's status callback and the regression tests align with the engine semantics. One non-blocking observation below.

[avifenesh]

This is an auto review done by revuto.

---

Reviewed the worker fileManager open-target patch. The core approach is sound — applyLinuxWorkerFileManagerPatch reuses the established findCallBlock + idempotency-guard pattern, the descriptor is registered as extracted-app/optional with a unique id, and the worker bundle is found/written from .vite/build/worker.js. One robustness concern on the open() implementation is worth confirming.

[avifenesh]

This is an auto review done by revuto.

---

Reviewed the worker fileManager open-target patch (PR #546). The approach mirrors the existing applyLinuxFileManagerPatch and reuses findCallBlock/requireName, registering a new extracted-app descriptor linux-worker-file-manager. One status-semantics concern worth confirming on the warning path; the rest looks consistent with the framework.

[avifenesh]

This is an auto review done by revuto.

---

When applyLinuxWorkerFileManagerPatch fails for a recoverable-but-real reason, the returned reason here can mislead the report. Concretely: if the id:fileManager`` block exists but requireName can't resolve `node:fs`/`node:path` (or `}});` insertion point is missing), `applyLinuxWorkerFileManagerPatch` emits a `console.warn` and returns the source unchanged. In `patchLinuxWorkerFileManagerTarget`, `hasPatchableBlock` (= `findCallBlock(...) != null`) is then `true` and `hasLinuxTarget` is `false`, so this branch returns `reason: "fileManager target found but Linux worker patch was not applied"` — but the descriptor `status` callback in window-shell/patch.js keys off `warnings.length`/`result.reason` and the `console.warn` is captured by the engine, so it is reported as `skipped-optional` drift (correct). However, in the normal already-applied case (`block.text.includes("linux:{")` -> early return at line 67), the source is unchanged, `hasLinuxTarget` is `true`, `reason` is `null`, and no warning fires — so the descriptor status resolves to `already-applied` (correct). The edge to confirm: an upstream bundle where the worker `fileManager` block already contains some other `linux:{...}` key (not the File Manager target) would hit the line-67 early return, mark `already-applied`, and silently skip injecting the Linux target. The main-bundle `applyLinuxFileManagerPatch` has the identical `includes("linux:{")` guard, so this matches existing behavior — but worth a quick check that no real worker bundle ships an unrelated `linux:{` in that call block.

[ilysenko]

Reviewed current head 28a1479 after the worker alias update. CI is green; local validation passed: node --test scripts/patch-linux-window-ui.test.js, git diff --check, node --check for changed patcher files, and real app.asar worker sanity check. No blockers found.