Files
multica/server/internal/daemon/execenv
a54662f30e fix(daemon): provision config-referenced Codex instruction files into task home (#6291)
* fix(daemon): provision config-referenced Codex instruction files into task home

A per-task CODEX_HOME copies the user's config.toml verbatim, so a
model_instructions_file reference survived the move while the file it
names did not. Codex resolves the relative value against CODEX_HOME —
now the task home — and failed loading its configuration before the task
prompt was ever delivered (#6271).

Generalize the existing model_catalog_json provisioning into a keyed
table of path-valued config keys and add model_instructions_file plus its
deprecated experimental_instructions_file alias. Semantics are unchanged
per key: absolute/~ values are left for Codex to read directly, relative
values must stay inside the task home, the copy refreshes on reuse, and a
missing source fails during environment preparation with a diagnostic
naming the key instead of an opaque os error 2 at thread/start.

Co-authored-by: multica-agent <[email protected]>

* fix(daemon): root-scope task-home writes for config-referenced Codex files

Review must-fix: filepath.IsLocal only proves the config string has no
lexical '..'. A task home is reused, and the task that ran in it can
replace an intermediate directory of the copy destination with a symlink,
which made the daemon's next MkdirAll/Remove/copy follow that link and
delete or overwrite a file outside the task home.

Do the mkdir, stale-copy removal, and write through os.OpenRoot(codexHome)
so links leaving the task home are rejected (links staying inside it are
harmless), and refuse outright when codexHome itself is a symlink, since
OpenRoot would resolve it before confining anything below. The pre-existing
model_catalog_json path is covered by the same helper.

Also stop reporting every source stat failure as a missing file — a
permission or IO error now says so — and document the source-side symlink
policy plus the stale-copy contract.

Co-authored-by: multica-agent <[email protected]>

* test(daemon): pin stale-copy contract when a referenced Codex file is repointed

Co-authored-by: multica-agent <[email protected]>

* fix(daemon): bind codex-home root check to the opened handle

Review must-fix: checking the path with os.Lstat and then opening it with
os.OpenRoot leaves a window where the directory is swapped for a link to
somewhere else. OpenRoot resolves the path it is given, so the resulting
root is confined to the wrong tree and every root-scoped write lands
outside the task home without ever escaping its root. Task homes are
reused and Windows cannot confirm descendant cleanup, so a leftover
process that knows its old CODEX_HOME can create that window.

Open first, then prove identity against the handle: compare root.Stat(".")
with a no-follow os.Lstat of codexHome via os.SameFile, and reject a
symlink outright. A swap before the open now fails the check; a swap after
it cannot matter because all writes go through the verified handle.

verifyCodexHomeRoot is split out so the swap is tested deterministically
instead of raced, plus an end-to-end test for a task home that is already
a link to an outside directory.

Co-authored-by: multica-agent <[email protected]>

* docs(daemon): scope the codex-home symlink test name and root-handle claim

Review nit: the end-to-end test asserted only that the referenced-file copy
refuses a symlinked task home, but its name read as though the whole
prepare were safe. Rename it accordingly and state in both the test and
openVerifiedCodexHomeRoot that the earlier path-addressed steps of
prepareCodexHomeWithOpts are out of scope, tracked in MUL-5647.

Co-authored-by: multica-agent <[email protected]>

---------

Co-authored-by: Eve <[email protected]>
Co-authored-by: multica-agent <[email protected]>
2026-08-03 16:23:43 +08:00
..