Refuted findings 7
Candidates the review stage examined and rejected, kept for transparency.
Code execution
criticalRefutedlow confidenceThe do-act tool runs an agent-supplied shell command through /bin/sh -c (the 'verify' parameter); this is documented as the tool's verification step and fits its purpose, but it gives the calling agent arbitrary shell execution outside the Codex sandbox.
['-c', `cd ${JSON.stringify(workingDir)} && ${command}`]Why it was refuted
The shell verify command is the declared purpose of do-act. The schema describes it as a 'Shell command to verify result' and the tool description says it verifies with a shell command. This is a declared core capability.
Code execution
criticalRefutedlow confidenceThe do-act tool passes the caller-supplied `verify.command` string into `/bin/sh -c` (or `cmd /c`) and executes it on the host, which is arbitrary command execution by design.
: ['-c', `cd ${JSON.stringify(workingDir)} && ${command}`];Why it was refuted
This is the same runVerify shell execution as the previous finding, and it is the declared verification feature of do-act. The shell command is openly described in the schema, so it is not concealed.
Privilege escalation
highRefutedlow confidenceThe ask-codex tool exposes a `bypassHookTrust` option that runs enabled hooks without persisted trust, which lets a calling agent weaken Codex's hook-trust safety control.
DANGEROUS: run enabled hooks without persisted hook trust
Why it was refuted
bypassHookTrust is an opt-in parameter that forwards a Codex CLI flag, openly labelled DANGEROUS in the tool schema. This is the declared core capability of a Codex wrapper, so nothing is concealed.
Privilege escalation
highRefutedmedium confidenceThe server exposes an agent-callable 'yolo' parameter (also bypassHookTrust and danger-full-access sandbox) that maps to Codex's --dangerously-bypass-approvals-and-sandbox, letting the calling model disable the sandbox and approvals; this is openly labelled and consistent with a Codex wrapper, so it is a contextual risk rather than a concealed behavior.
Bypass all safety (dangerous)
Why it was refuted
The yolo, sandboxMode and bypass options are explicit, labelled pass-throughs of Codex CLI flags and are opt-in. The builder also rejects conflicting combinations. This is a declared core capability, not a concealed behavior.
Manipulation
highRefutedlow confidenceChange-mode output text tells the consuming agent to apply the edits directly without first reading the files, which discourages verification of Codex-generated edits.
IMPORTANT: Apply these edits directly WITHOUT reading the files first.
Why it was refuted
The line is a workflow hint for applying the tool's own changeMode edits, not a security-control bypass. The footer states the edits use exact string matching, so a stale or mismatched edit fails instead of silently applying.
Privilege escalation
highRefutedlow confidenceThe Codex command builder exposes an opt-in 'yolo' option that passes the permission/sandbox-bypass flag to the Codex CLI; this fits the wrapper's purpose but is a real bypass capability (the detector hit itself is only a comment mention).
this.args.push(CLI.FLAGS.YOLO);
Why it was refuted
The yolo branch is an opt-in pass-through of a documented Codex CLI flag. The builder rejects yolo combined with approval or sandbox options. This is the declared core capability of a Codex wrapper, and the flag is documented in constants and the tool schema.
Privilege escalation
mediumRefutedlow confidenceThe do-act tool defaults to automation mode (fullAuto on, writable sandbox, approval 'never') and runs a caller-supplied shell verify command; this is disclosed in the tool description and is the tool's core purpose, but the default silently removes approval prompts.
fullAuto: fullAuto !== false,
Why it was refuted
The fullAuto default expands to a workspace-write sandbox with approval never, not a sandbox bypass. The code comment says the sandbox remains active, and the tool is annotated destructive. The behavior matches the declared automation purpose.
