Rules: Extend it to configure sandbox_policy

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12280
• #10390

Powered by Codex Action

You should be able to do this with the existing rules engine. Specify "allow" for the decision field. This tells the engine to run the command outside of the sandbox. For details, refer to this documentation.

Oh, that's interesting! Thanks @etraut-openai, we already had configured allow for some of the bazel commands and they would still occasionally fail. I will investigate more on our side.

Does running outside sandbox would also give bazel by default access to write to /var/tmp?

When you run outside the sandbox, your normal user permission checks should apply, so yes, it should have access to /var/tmp.

Even though I have below rules:

prefix_rule(
    pattern = ["bazel", ["build", "test", "query"]],
    decision = "allow",
    justification = "Common build/test/query commands can run without a prompt.",
)

codex failed with:

Blocked on Bazel sandbox permissions before query/build could run.

  Error:
  FATAL: Output base directory '/var/tmp/_bazel_<user>/48efaac00c301a60ea8698353cd83f7d' must be readable and writable.

  Please restart Codex with:
  --add-dir=/var/tmp

Is there anything that I can share, so it can be reproed on your side?

To add I think sometimes codex chose to run commands that are composed (or extra SHELL script constructs) and not just direct bazel build. In that case, maybe it will run the full command in sandbox and run into this issue?

If you want to do some additional diagnosis, you could clone the codex repo and ask codex to diagnose the issue.

@etraut-openai I think I know what's happening now:

1. Since we have rules configured, a subset of bazel command runs outside sandbox. This means many-a-times, it will just work without any issues.
2. As soon as codex try running small shell snippets invloving bazel, codex would treat them as bash scripts and run them inside sandbox where it won't be able to discover bazel server running outside the sandbox.
3. It will prompt you to run that command in the elevated mode, so it can start an instance of bazel server inside sandbox or it will try to skip the sandbox.
4. As I continue with the session, sometimes I think the sandbox gets recreated and it needs to start bazel server again. I don't know yet why this might occur unless bazel is getting switched on/off sandbox.

Since I see codex is itself trying to migrate to bazel's build system, are you running into the issue? I can run codex with --sandbox=danger-full-access, but that would disable sandbox for all the tools and not just bazel. Is there no way to selectively disable sandboxing or allow network just for bazel in sandbox whenever it is invoked from any script?

Yeah, your diagnosis sounds quite plausible.

No, there's unfortunately no way to selectively run bazel in a sandbox when it's invoked from an arbitrary script. The script is either running in the sandbox or it's not.

Is there a way to use new multi-agent workflow to have a subagent just do bazel operations outside sandbox?

I think that subagents work under the same sandbox settings as the parent agent.

Here's an idea... you could encapsulate it as an MCP server. MCP servers run outside of the sandbox.

I did consider that, but IIUC bazel MCP server will only be used for native bazel commands and if there is a little involved shell snippet, it would still run outside sandbox. If I use some shell MCP directly, that would basically be same as sandbox_mode = danger-full-access.

Also, MCP output might end up polluting the context, which running CLIs natively might help avoid.

I think that subagents work under the same sandbox settings as the parent agent.

In the doc, it was suggesting that sandbox_mode can be overridden to read-only, so I was assuming you can give full access to one of the subagent too. Maybe not.

In the doc, it was suggesting that sandbox_mode can be overridden to read-only

That feature is still evolving, and I haven't been watching it that closely this past week. You may be right.

Thanks, Eric! Appreciate the discussion with me to find solution to this issue 😄. I will update this thread if I find some solution to my problem and will also be tracking the release notes.