Grok: config-based permission deny rules + agent sandbox both bypassed under Codeg's ACP hosting (auto mode + fs/terminal channel)

[5ninefish]

Summary

Two related gaps make it currently impossible to reliably block Grok Build from reading a specific file (e.g. a .env secrets file) when Grok is run inside Codeg, even with permission rules and Grok's own OS-level sandbox both correctly configured.

Finding 1: permission_mode = "auto" does not honor config.toml [permission] deny rules

Grok's own docs (docs/user-guide/22-permissions-and-safety.md) state deny rules always win over the permission mode, including auto. In practice, with [ui] permission_mode = "auto" set (either via ~/.grok/config.toml, <project>/.grok/config.toml, or the --permission-mode auto CLI flag — this is also what Codeg passes when launching Grok), a [permission] rules deny entry for a read tool pattern does not block the read. The file is read successfully with no denial, no prompt, and no error.

Explicit CLI --deny 'Read(**/.env_test)' flags do work correctly and are honored even under --permission-mode auto — this matches the documented behavior. Only the config-file-sourced [permission] rules array appears to be silently ignored specifically when permission_mode is auto.

Reproduction:

# config.toml
[ui]
permission_mode = "auto"

[permission]
rules = [
  { action = "deny", tool = "read", pattern = "**/.env_test" },
]

echo 'CANARY=fake' > .env_test
grok -p "Read .env_test and report its contents."
# Expected: blocked
# Actual: contents printed successfully

# Same config, explicit CLI --deny instead of relying on config.toml rules:
grok --deny 'Read(**/.env_test)' -p "Read .env_test and report its contents."
# Correctly blocked, as documented

Finding 2: Grok's OS-level sandbox (--sandbox <profile> / [sandbox] profile) is not effective when Grok is hosted via Codeg's ACP integration

Verified via Grok's own ~/.grok/sandbox-events.jsonl audit log, which is unambiguous:

• Standalone Grok CLI, with a custom sandbox profile denying .env_test (~/.grok/sandbox.toml / .grok/sandbox.toml, deny = ["**/.env_test"]), set as the default via [sandbox] profile = "..." in config: reads are correctly blocked, FsViolation events are logged in the audit trail.
• Same exact profile, same config, launched via a Codeg custom ACP agent entry (grok --sandbox dbrain-safe --no-auto-update agent stdio, confirmed via ps to be the actual running command): the ProfileApplied event IS logged (enforced: true, correct deny_paths list) — so the sandbox genuinely activates for the process — but the file is still read successfully, and no FsViolation is ever logged.

This strongly suggests Codeg's ACP fs/read_text_file (and/or terminal) channel services the request outside Grok's own sandboxed process boundary — i.e. Codeg's own (unsandboxed) host process may be reading the file and handing the content to Grok over the protocol, rather than Grok's own sandboxed process performing the read.

This appears to be acknowledged in Codeg's own source: src-tauri/src/acp/file_system_runtime.rs documents that ACP fs/read_text_file access defaults to unrestricted specifically because restricting it doesn't add safety, since an agent can fall back to run_terminal_command (observed with Grok specifically, via a cat > ... << 'PLAN_EOF' heredoc). If the terminal channel is also serviced outside the agent's sandboxed process (unconfirmed, but consistent with the audit-log evidence above), then neither CODEG_ACP_FS_POLICY=strict nor the agent's own OS sandbox can currently provide a real guarantee against file exfiltration through Codeg, for any agent whose sandbox operates at the process level rather than being enforced by Codeg itself.

Impact

For any multi-agent setup where Codeg hosts an agent alongside sensitive project files (e.g. .env secrets), there is currently no configuration — on the agent's side or via CODEG_ACP_FS_POLICY — that reliably prevents that agent from reading those files when hosted through Codeg, even though the identical agent CLI, run standalone with the identical configuration, is correctly and verifiably blocked.

Suggested direction

If the terminal channel is confirmed to bypass the agent's own sandbox the same way the fs channel does, the fix likely needs to live in Codeg itself — e.g. running the ACP-hosted agent process (including its terminal/shell tool) inside the same OS-level sandbox boundary Codeg advertises to it, rather than relying on the agent's own self-reported sandbox status, or enforcing CODEG_ACP_FS_EXTRA_ROOTS/deny-lists at the Codeg host-process level for both the fs and terminal channels consistently.

Happy to provide more detail or test a patch — this was found while building a multi-agent (Claude Code / Codex / Grok) workflow on top of Codeg and trying to establish a real security boundary around a secrets file shared across all three agents' sessions.