Files
dev/code-rs/core
zeekay 4fa6daf138 shot: test the contract with cloud, and stop trusting the caller's paths
The screenshot publisher landed in 3a72312dda, a commit whose subject is about
the Hanzo provider's machine credential and which mentions none of it. This
finishes it and writes down what it is.

Two things it was getting wrong, both found by mutating the code and watching
which test failed:

The payload promised workspace-relative filenames and there was nothing making
that true. A turn diff names files relative to the git root when there is one and
absolutely when there is not, so an agent run outside a repository would have
published the operator's home directory — and their account name — into a log the
whole org reads. `ui::named` relativizes against the workspace and falls back to
the bare filename for anything still absolute, which a diff can produce because
it can name a file the workspace does not contain. The old test asserted the
absence of "/home/..." over a fixture that was already relative, so it passed
whatever the code did; the new one starts from absolute inputs.

Nothing exercised the three calls to cloud. They are now driven against wiremock,
which pins the door (`/v1/s3/buckets/sessions/objects`, then the signed PUT, then
`/v1/agents/sessions/{id}/events`), the exact payload, and the part that actually
matters: the org bearer goes to the two API calls and NOT to the presigned URL,
because the signature is that URL's credential and our token would be a second
one handed to whatever host cloud signed against. Adding `.bearer_auth` to the
upload turns that test red, which is the whole point of writing it.

Also covered: a session id out of the environment reaching a URL path, refused
unless it is alphanumeric-plus-dash-underscore, so `../../admin` cannot retarget
the append at another tenant's session; and cloud's 422 refusal surfacing as an
error rather than being read as success.

LLM.md records the subsystem, since its arrival in the history is mislabelled and
the next reader has no way to find it from the log.
2026-08-07 14:29:17 -07:00
..

codex-core

This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.

See also: Slash Commands for a complete list of interactive commands available in the TUI.

Dependencies

Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this

macOS

Expects /usr/bin/sandbox-exec to be present.

Linux

Expects the binary containing codex-core to run the equivalent of codex debug landlock when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.

All Platforms

Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.