From 5d833466bba5a36c178557f81f345aa28a2e5511 Mon Sep 17 00:00:00 2001 From: Craig Osterhout Date: Fri, 10 Jul 2026 14:37:32 -0700 Subject: [PATCH] sbx: update policy output Signed-off-by: Craig Osterhout --- content/manuals/ai/sandboxes/governance/local.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/content/manuals/ai/sandboxes/governance/local.md b/content/manuals/ai/sandboxes/governance/local.md index 008aa118bd8..143ae4da264 100644 --- a/content/manuals/ai/sandboxes/governance/local.md +++ b/content/manuals/ai/sandboxes/governance/local.md @@ -138,8 +138,8 @@ $ sbx policy reset --force If rules you add with `sbx policy allow` or `sbx policy deny` don't change sandbox behavior, your organization likely has governance enabled. Run `sbx -policy ls` to check: if the output starts with a `Policy rules` header listing a -`Governance Managed by ` line, org governance is active. When it's active, +policy ls` to check: if the output starts with a `Governance:` status line +showing `Managed by `, org governance is active. When it's active, the organization policy replaces local policy, so your rules have no effect. They're hidden from `sbx policy ls` by default; run `sbx policy ls --include-inactive` to see them with an `inactive` status in the `STATUS` @@ -154,8 +154,7 @@ the Admin Console. If a domain remains blocked after you add a local allow rule, your organization likely enforces governance, which makes local rules inactive. Run `sbx policy ls` to check whether org governance is active; if the output starts with a -`Policy rules` header listing a `Governance Managed by ` line, it is. Add +`Governance:` status line showing `Managed by `, it is. Add `--include-inactive` to confirm your rule shows an `inactive` status. If so, the -block can only be -lifted by updating the org policy in the Admin Console or via the -[API](/reference/api/ai-governance/). +block can only be lifted by updating the org policy in the Admin Console or via +the [API](/reference/api/ai-governance/).