← All activity records

FACTUAL ACTIVITY RECORD · An activity record based on work that took place

Returning command execution to the standard approval model

Removing excessive custom controls while preserving safety boundaries and human judgment

Activity period:

Purpose

Layered custom allow classifications, a default-deny hook, and dedicated wrappers had made both routine work and lifecycle actions such as exceptions and cancellation prone to deadlock.

Execution needed to return to the standard sandbox and approval decisions while retaining secret non-disclosure, protection from destructive actions, preservation of user changes, and human approval for consequential operations.

Implementation

Broad custom command allow and deny rules were reduced, leaving only recursive forced deletion explicitly forbidden. Other commands returned to the runtime sandbox and approval decision, with direct execution requiring a clear target and impact when approval was needed.

The hook that denied commands by default and the wrappers that fixed every execution path were removed. Git and external-service operations now fix their scope, run directly, and reread the resulting external state through the same route after a change.

  • Do not expose or record secrets, credentials, account email, or raw connection destinations.
  • Do not perform forced updates, broad discards, or deletion of remote work references without explicit approval of the target and impact.
  • Preserve the defined human approval boundaries for consequential publication, application, and lifecycle state changes.
  • When work leaves the normal path, separate confirmed facts, unknowns, actual blockers, and residual risks.

The first check found inconsistencies in lifecycle ownership, verification of other areas, treatment of auxiliary observation records, and possible disclosure while checking connection destinations. Ownership was clarified, other areas were made subject to direct verification, missing auxiliary records ceased to be a blocker by themselves, and raw destinations were removed from standard checks.

Configuration, agent definitions, skills, operating documentation, and review procedures were synchronized to the same boundaries. Format parsing, references to removed routes, forbidden-rule shape, and diff consistency were checked while retaining the existing agent inventory and execution capacity.

In the final state, recursive custom-hook enforcement was removed from configuration and the standard approval policy and workspace sandbox became authoritative again.

.codex/config.toml — standard approval and sandbox settings (excerpt)Exact implementation excerpt
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"
project_doc_max_bytes = 65536
project_root_markers = [".git", "AGENTS.md"]
Execution boundary restored to the standard approval model

Rendering diagram…

What was confirmed

Verification results

Custom rules were reduced to one prohibition on recursive forced deletion, with no broad allow classification or default-deny hook remaining.

Current procedures no longer depended on removed wrappers or auxiliary routes and consistently used direct operations followed by rereading actual state.

The three safety and responsibility inconsistencies found in the first check were corrected, and the second check had no unresolved finding.

Format parsing, syntax checks, reference searches, forbidden-rule checks, and diff consistency passed, and the changes were applied to the target. Residual risks are the absence of continuous automated checks and reliance on standard approval boundaries for alternate spellings of forbidden operations.

Basis for completion

The work was complete when custom execution controls had been minimized, removals and references had been checked across the active scope, safety boundaries, ownership, and exception handling had been aligned, and format, syntax, rule, and diff checks had passed on the result applied to the target.