Never patch authority state in place
Use when: a Codex session can change repository trust or its permission profile without restarting the client. This matters most for downloaded worktrees, shared repositories, managed developer machines, and app-server clients that send request-specific permission profiles. On older builds, the displayed trust or profile could change while the effective instruction or filesystem boundary remained stale.
@openai/[email protected]
or
later.
Mark
unfamiliar
checkouts
with
trust_level="untrusted"
under
their
absolute
[projects."…"]
entry.
Keep
non-negotiable
secret
paths
in
managed
requirements.toml
as
permissions.filesystem.deny_read,
not
only
in
a
user-selectable
profile.
After
any
trust
or
/permissions
update,
rebuild
the
instruction
chain
from
the
new
trust
state,
then
merge
managed
denials
into
the
selected
profile.
Reject
a
conflicting
profile
instead
of
widening
it.
Custom
harnesses
should
key
instruction
caches
by
project
identity
and
trust
level.
Acceptance
check:
create
a
disposable
repository
whose
AGENTS.md
contains
PROJECT_INSTRUCTION_CANARY,
plus
a
global
AGENTS.md
containing
GLOBAL_INSTRUCTION_CANARY.
With
the
project
untrusted,
a
fresh
session
must
report
only
the
global
canary;
after
explicitly
trusting
it,
a
fresh
session
must
report
both.
Next,
deny
a
synthetic
secret
file
through
managed
deny_read
and
leave
an
adjacent
public
file
readable.
The
public
read
must
pass;
the
secret
read
must
fail
before
and
after
switching
from
Workspace
to
Read
Only
and
back
through
/permissions.
Inspect
active
instruction
sources,
the
effective
profile,
and
actual
read
results,
not
the
agent’s
explanation.
0.150.0
release
ships
both
repairs.
Merged
PR
#39837
adds
trust
to
the
instruction-cache
key,
skips
project
discovery
when
untrusted,
and
tests
runtime
trust
switches.
Merged
PR
#40004
retains
managed
denials
separately,
rejects
conflicting
updates,
and
tests
thread
and
command/exec
paths.
Current
official
configuration
and
managed-policy
documentation
matches
those
boundaries.
Caveat: project trust controls project-scoped instructions, configuration, hooks, and rules; it does not make repository content safe to execute. Managed read-deny enforcement also remains platform-specific: the current documentation warns that native Windows shell subprocess reads do not use this sandbox rule. Canary every model-reachable read plane on the deployed platform.