Codex scheme for operations requiring secret access after "setup" runs

The issue of no safe way to make use of secret-using operations post-setup is an almost immediate blocker to serious use of Codex when there are dependencies on private package registries or other private git repos, etc.

A couple other topics have also touched on the issue of the need for “secret-using” operations to be performed by the agent after setup (refs below).

I think there’s a fairly simple scheme to address the most common cases.

Usually, we just want the agent to be able to update dependencies or perform other read-only operations requiring secrets. Adding the ability to:
(a) Define a sandboxed dependency install script (with secret access) just like the setup script, that could be called by the agent, or
(b) Allow the definition of a sandboxed wrapper script for any named executable that can handle secret passing like the setup script does

The truth is, every shell command is a sandboxed tool call anyway, so the mechanism already exists to catch each shell invocation. The change in (a) is to grant access to a new parameterless script, or (b) to hook every run of a particular cli command for handling by a user script.

Other topic refs

Useful framing. I’d split “secret-using operations” into at least two shapes:

  1. setup/CLI secrets that a sandboxed wrapper can use
  2. browser/login secrets where the agent should never receive the value at all

I’m building AgentPass Local for the second case: local OS-protected credentials, allowed domains as the policy boundary, browser-field fill, and outcome-only handoff back to the agent. Same underlying need: the agent gets permission to complete the work, not general visibility into the secret.