Skip to content

Container script firewall is overly restrictive #376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
BadPirate opened this issue Apr 18, 2025 · 5 comments · May be fixed by #383
Open

Container script firewall is overly restrictive #376

BadPirate opened this issue Apr 18, 2025 · 5 comments · May be fixed by #383
Labels
bug Something isn't working

Comments

@BadPirate
Copy link
Contributor

What version of Codex is running?

0.1.2504172351

Which model were you using?

any

What platform is your computer?

MacOS

What steps can reproduce the bug?

  1. use run-in-container.sh script to open codex
  2. Ask codex to ping google.com

Expectation:

Should be able to make benign internet requests

Actual:

All outbound traffic is blocked, this forces manual interventions for adding tools (which is fine because it's in the container), running commands like yarn install among many other little grievances.

What is the expected behavior?

Docker container should protect / prevent calls to host machine, but allow internet access.

What do you see instead?

No response

Additional information

No response

@BadPirate BadPirate added the bug Something isn't working label Apr 18, 2025
@BadPirate
Copy link
Contributor Author

Note: I'm looking into this for myself but wanted to drop an issue as I assume this behavior others will want.

BadPirate added a commit to BadPirate/codex that referenced this issue Apr 19, 2025
Added --allow-outbound flag to the run_in_container.sh script tree,
if set, outbound firewall rules won't be turned on allowing container
to connect to things like npm, run tests, perform git actions etc.

Signed-off-by: BadPirate <[email protected]>
BadPirate added a commit to BadPirate/codex that referenced this issue Apr 19, 2025
Added --allow-outbound flag to the run_in_container.sh script tree,
if set, outbound firewall rules won't be turned on allowing container
to connect to things like npm, run tests, perform git actions etc.

Signed-off-by: BadPirate <[email protected]>
@BadPirate BadPirate linked a pull request Apr 19, 2025 that will close this issue
@fouad-openai
Copy link
Collaborator

This is actually intentional, at least for now - sorry for the confusion and lack of documentation! There's a few different risks when it comes to outbound network access, like:

  • Prompt injection
  • Installing packages without approval (could have vulnerabilities)
  • Data exfiltration (accidental or caused by prompt injection, like posting a user's code on the internet)

We'll have guidance soon on how to do this safely, but since you've already started #383 I think it's reasonable to expose an argument like --dangerously-allow-network-outbound (added as comment on your PR) - lmk if you have questions!

@BadPirate
Copy link
Contributor Author

Oh sorry, just noted your response here. What you say makes sense. If it is really dangerous, I might recommend opening an issue with the Mac client sandbox, Apple's sandbox-exec allows for blocking outbound network in the profile you provide when you use it, but based on my testing the current cli isn't doing so at the moment. I'll accept your changes.

@ikamensh
Copy link
Contributor

ikamensh commented Apr 20, 2025

I was thinking about safe browsing too - could it be server side like when using chatgpt? so not doing request from client machine but from openai servers. I assume the standard browsing on chatgpt already has features of not being able to post user content; due to sandboxing any prompt injection would be limited to failing the task at hand. I guess worst case is it proposes vulnerable, hacked code to the user and user is not paying attention?

The utility I'm looking for is reading related docs and repos that are on the internet.

@BadPirate
Copy link
Contributor Author

For my use case at least, I found the apple sandbox and the container sandbox overly restrictive. Simple case: Asking codex to make changes, and test those changes before coming back to me (Otherwise I have to go multiple rounds as it stumbles through development)

    I ran npx next lint and everything is clean—no ESLint errors.

    However, when I try to run the Playwright suite (yarn test / npx playwright test), it can’t even
    start the Next.js dev server in this sandbox (it errors out with “EPERM: operation not permitted …
    listen 127.0.0.1:3000”). Because I can’t bind to a port here, the web server never comes up and the
    tests abort immediately.

    Could you let me know how you’d like me to proceed? For example:

        * Should I stub out or mock the web server in Playwright config so tests can run without
    launching Next.js?
        * Should I point them at an already‑running instance instead?
        * Or would you prefer to share the test‑output locally so I can diagnose the warnings you’re
    seeing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants