Provider Permission Matrix (v0.1.x)
This document freezes provider permission-key behavior for mco run / mco review in v0.1.x.
Global Enforcement Semantics
enforcement_mode=strict(default):- if config requests unsupported permission keys for a provider, that provider fails closed with
reason=permission_enforcement_failed.
- if config requests unsupported permission keys for a provider, that provider fails closed with
enforcement_mode=best_effort:- unsupported permission keys are dropped before adapter execution.
- provider continues with only supported keys.
Matrix
| Provider | supported_permission_keys() |
Effective adapter mapping | Default behavior if key omitted |
|---|---|---|---|
claude |
["permission_mode"] |
permission_mode -> claude --permission-mode <value> |
permission_mode=plan |
codex |
["sandbox"] |
sandbox -> codex exec --sandbox <value> |
sandbox=workspace-write |
gemini |
[] |
No permission-key mapping in adapter | N/A |
opencode |
[] |
No permission-key mapping in adapter | N/A |
qwen |
[] |
No permission-key mapping in adapter | N/A |
Strict vs Best-Effort Examples
Given config:
{
"policy": {
"enforcement_mode": "strict",
"provider_permissions": {
"gemini": { "sandbox": "workspace-write" }
}
}
}
strict:geminifails withpermission_enforcement_failed.best_effort:sandboxis dropped (since unsupported),geministill runs.
Important Boundary
allow_pathsis orchestrator-level validation, not OS-kernel sandboxing.- Real process sandboxing/isolation remains provider-specific.