Summary

The safeBinProfiles config schema does not expose the knownLongFlags field, even though it is used internally by validateSafeBinArgv for GNU long-option abbreviation resolution. Attempting to set knownLongFlags in a profile causes a Zod .strict() validation crash: "Unrecognized key(s) in object: 'knownLongFlags'".

This means operators cannot declare long flags as "known" without also categorizing them as allowedValueFlags or deniedFlags, which have different semantics.

Reproduction

In settings.json or agent config:

{
  "tools": {
    "exec": {
      "security": "allowlist",
      "safeBins": ["mycli"],
      "safeBinProfiles": {
        "mycli": {
          "knownLongFlags": ["--mode", "--file", "--version"]
        }
      }
    }
  }
}

Expected: Profile accepts knownLongFlags and uses them for long-option resolution. Actual: Config parse crash — Unrecognized key(s) in object: 'knownLongFlags'

Root Cause

In src/config/zod-schema.agent-runtime.ts, ToolExecSafeBinProfileSchema uses .strict() and only defines four fields:

const ToolExecSafeBinProfileSchema = z
  .object({
    minPositional: z.number().int().nonnegative().optional(),
    maxPositional: z.number().int().nonnegative().optional(),
    allowedValueFlags: z.array(z.string()).optional(),
    deniedFlags: z.array(z.string()).optional(),
  })
  .strict();

The knownLongFlags field exists in the internal SafeBinProfile type (src/infra/exec-safe-bin-policy-profiles.ts:7) and is used by collectPositionalTokens() in exec-safe-bin-policy-validator.ts (line 140-143), but it is not present in:

1. The Zod schema (ToolExecSafeBinProfileSchema) — causes the parse crash
2. The SafeBinProfileFixture type — no way to pass it through config normalization

Currently, knownLongFlags is auto-derived from allowedValueFlags ∪ deniedFlags (collectKnownLongFlags()). For an empty profile {}, both sets are empty, so knownLongFlags = [] — meaning all long flags are treated as unknown and rejected by consumeLongOptionToken().

Impact

Operators running headless/containerized deployments who add custom binaries to safeBins with empty profiles {} cannot make any long flags pass the third validation gate. The only workaround is to list every possible long flag in either allowedValueFlags or deniedFlags, which is impractical and changes their allow/deny semantics.

Proposed Fix

1. Add knownLongFlags: z.array(z.string()).optional() to ToolExecSafeBinProfileSchema
2. Add knownLongFlags to the SafeBinProfileFixture type
3. Update normalizeSafeBinProfileFixture to normalize knownLongFlags via the existing normalizeFixtureFlags helper
4. Update compileSafeBinProfile to merge user-provided knownLongFlags with the auto-derived set from allowedValueFlags ∪ deniedFlags

This is a backwards-compatible, additive schema change. Existing configs without knownLongFlags continue to work identically via auto-derivation.

Happy to submit a PR for this.