Description

Durable approval (durableApprovalSatisfied) is used to skip approval prompts and to treat allowlist misses as allowed.

In invoke-system-run.ts, an allow-always decision now persists a durable exact-command approval when resolveAllowAlwaysPatterns() returns no patterns:

• This happens even when command analysis is not OK (e.g., shell parsing fails, line continuations, unsupported constructs), because there is no analysisOk gate.
• The resulting durable entry later makes requiresExecApproval() return false early and makes evaluateSystemRunPolicy() return allowed: true even on allowlist-miss.

This creates an authorization bypass where a user (or automation) can permanently “bless” a command that the allowlist analyzer cannot safely understand, and then execute it later without prompts and without enforced allowlist planning (including the fail-closed shell-wrapper block).

Vulnerable flow:

• Input: commandText (potentially unanalyzable / contains shell wrappers / complex shell syntax)
• Persistence: durable approval added when patterns.length === 0
• Enforcement bypass: allowlist-miss becomes allowed when durableApprovalSatisfied is true

Vulnerable code:

if (phase.policy.approvalDecision === "allow-always" && phase.inlineEvalHit === null) {
  const patterns = resolveAllowAlwaysPatterns({ segments: phase.segments, ... });
  ...
  if (patterns.length === 0) {
    addDurableCommandApproval(phase.approvals.file, phase.agentId, phase.commandText);
  }
}

And later:

if (params.security === "allowlist" && (!analysisOk || !allowlistSatisfied) && !approvedByAsk) {
  if (params.durableApprovalSatisfied) {
    return { allowed: true, ... };
  }
  return { allowed: false, eventReason: "allowlist-miss", ... };
}

Recommendation

Do not grant (or honor) durable approvals unless the command was successfully analyzed and deemed safe under the allowlist model.

Recommended changes:

1. Only persist durable approvals when analysis succeeds and the allowlist is satisfied, and when no additional risky flags are present (obfuscation/heredoc/shell-wrapper/inline-eval/etc.). For example:

if (
  phase.security === "allowlist" &&
  phase.policy.approvalDecision === "allow-always" &&
  phase.policy.analysisOk &&
  phase.policy.allowlistSatisfied &&
  phase.inlineEvalHit === null &&
  !phase.shellPayload // if present, require explicit approval each time or persist per-inner-exe patterns only
) {
  const patterns = resolveAllowAlwaysPatterns({ ... });
  if (patterns.length > 0) {
    for (const pattern of patterns) {
      addAllowlistEntry(file, agentId, pattern, { source: "allow-always" });
    }
  } else {
    ​// Consider NOT creating durable approvals here; instead require explicit approval on each run.
  }
}

2. In evaluateSystemRunPolicy(), do not allow durable approval to override shell-wrapper blocking (fail-closed). Durable approval should not re-enable blocked constructs:

if (shellWrapperBlocked) {
  ​// never bypass with durable approval
}

3. Optionally, treat analysisOk === false as always requiring approval (ask), even if a durable entry exists, to avoid permanently trusting unanalyzable command strings.

Description

exec approvals can be bypassed in “headless” mode by setting trigger: "cron".

Flow:

• When exec approvals cannot be delivered (e.g., no interactive approval route), createAndRegisterDefaultExecApprovalRequest() sets preResolvedDecision to null, which maps to unavailableReason: "no-approval-route".
• shouldResolveExecApprovalUnavailableInline() explicitly allows an inline resolution when:
  • trigger === "cron"
  • unavailableReason === "no-approval-route"
  • preResolvedDecision === null
• createExecApprovalDecisionState() delegates to resolveBaseExecApprovalDecision(), where decision === null and askFallback === "full" returns approvedByAsk: true.
• Both gateway and node hosts treat this approvedByAsk as sufficient to proceed:
  • Gateway returns { allowWithoutEnforcedCommand: true } when it cannot build an enforced allowlist command.
  • Node forwards approved: true and approvalDecision: "allow-once" into system.run.

Impact:

• Any code path that can set ExecToolDefaults.trigger to "cron" while askFallback is configured to "full" can execute commands without any human approval, even when approval prompting is configured (e.g., ask="always").
• This is an approval-gating bypass unless trigger is strictly restricted to trusted local automation contexts.

Vulnerable logic:

if (!params.decision) {
  if (params.askFallback === "full") {
    return { approvedByAsk: true, deniedReason: null, timedOut: true };
  }
}

combined with:

return (
  trigger === "cron" &&
  unavailableReason === "no-approval-route" &&
  preResolvedDecision === null
);

Recommendation

Treat "no-approval-route" as a hard deny for all triggers, or require an explicit, non-user-controllable policy flag distinct from trigger to enable headless auto-approval.

Suggested approach:

• Remove the implicit approval (askFallback === "full") for decision === null when approvals are unavailable.
• Or gate it behind a dedicated config such as headlessAutoApprove: true that is only set by trusted cron runner code (not via generic ExecToolDefaults).

Example fix (deny when no approval route):

export function resolveBaseExecApprovalDecision(params: {
  decision: string | null;
  askFallback: ResolvedExecApprovals["agent"]["askFallback"];
  obfuscationDetected: boolean;
  unavailableReason?: ExecApprovalUnavailableReason | null;
}) {
  if (params.decision === null && params.unavailableReason === "no-approval-route") {
    return { approvedByAsk: false, deniedReason: "no-approval-route", timedOut: true };
  }
  ​// existing logic...
}

Additionally:

• Ensure trigger cannot be set by untrusted callers (e.g., tool input / remote request / plugins) or validate it against an allowlist of trusted sources.

Description

In allowlist security mode, processGatewayAllowlist builds an enforced shell command intended to execute the resolved/approved executable path (via buildEnforcedShellCommand). On Windows, buildEnforcedShellCommand returns { ok:false, reason:"unsupported platform" }, leaving enforcedCommand undefined.

The new logic introduces a path where execution proceeds without an enforced command:

• When allowlistSatisfied is true but enforcedCommand cannot be built (allowlistPlanUnavailableReason != null), the code requires an approval.
• For headless/cron triggers with no approval route, shouldResolveExecApprovalUnavailableInline() can resolve the approval inline based on askFallback.
• The function then returns { allowWithoutEnforcedCommand: true }.
• createExecTool clears execCommandOverride when this flag is set, so runExecProcess() executes the original raw command string.

This weakens allowlist guarantees: the allowlist evaluation may have been satisfied based on a particular resolved executable (or intended resolution), but the actual raw execution on Windows can select a different executable due to Windows search order (current working directory before PATH, PATHEXT, etc.) or other resolution differences. This enables a practical allowlist bypass such as placing a malicious git.bat/git.exe in the working directory while the allowlist intended to permit only a trusted Git installation.

Vulnerable flow:

• Input: params.command (user/model-provided command text)
• Policy check: evaluateShellAllowlist(...) + allowlistSatisfied
• Enforcement failure: buildEnforcedShellCommand(..., platform=win32) => unsupported
• Sink: runExecProcess uses execCommand ?? command, so raw command executes when override cleared

Recommendation

Fail closed in allowlist mode when an enforced execution plan cannot be built, especially on Windows.

Options:

1. Deny execution when security=="allowlist" and buildEnforcedShellCommand fails (unless the user explicitly switches to security="full").
2. Alternatively, implement a Windows-specific enforced execution strategy (e.g., spawn without shell using a resolved absolute executable path + argv) so that allowlist evaluation and execution target are identical.

Example fail-closed change (conceptual):

if (security === "allowlist" && allowlistSatisfied && !enforcedCommand) {
  throw new Error(`exec denied: allowlist execution plan unavailable (${allowlistPlanUnavailableReason})`);
}

If a headless/cron flow must proceed, require an explicit durable allowlist entry that binds to an absolute path (not just command text) or require security="full" in configuration.

Description

hasDurableExecApproval() treats exact-command approvals as durable trust by matching =command:${sha256(commandText).slice(0,16)}.

Because only 64 bits of the SHA-256 digest are used, an attacker who can influence the command text and can get a user to approve one command could potentially create a different command with the same 64-bit prefix (birthday-style collision) and reuse the durable approval to bypass further approval prompts.

Key points:

• Approval token is derived from sha256(commandText) truncated to 16 hex chars (64 bits).
• 64-bit collision resistance is ~2^32 work, which is within reach for motivated attackers with GPU/parallel hashing.
• hasDurableExecApproval() uses this match to skip approvals even when analysisOk is false (intended for exact-command reruns), so a collision can become an authorization bypass.

Vulnerable code:

function buildDurableCommandApprovalPattern(commandText: string): string {
  const digest = crypto.createHash("sha256").update(commandText).digest("hex").slice(0, 16);
  return `=command:${digest}`;
}

Recommendation

Increase the approval identifier length so collisions are computationally infeasible, or use a keyed construction.

Safer options (choose one):

1. Store full SHA-256 (or at least 128 bits)

function buildDurableCommandApprovalPattern(commandText: string): string {
  const digest = crypto.createHash("sha256").update(commandText).digest("hex");
  ​// or: .slice(0, 32) for 128-bit if size is a concern
  return `=command:${digest}`;
}

2. Use HMAC with a local secret (prevents attacker-controlled chosen-collision reuse without the secret)

function buildDurableCommandApprovalPattern(commandText: string, secret: string): string {
  const digest = crypto.createHmac("sha256", secret).update(commandText).digest("hex");
  return `=command:${digest}`;
}

If backwards-compatibility is needed, consider supporting legacy 64-bit patterns only temporarily and migrating to longer tokens on next write.