In sandbox commands like flutter test / flutter analyze have no respond

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

• #15016
• #13987
• #14368

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Git Bash fails inside Windows sandbox with "couldn't create signal pipe, Win32 error 5" #15016 [[Windows] read-only sandbox mode causes MCP shell_command to stall indefinitely — no function_call_output returned #13987](https://github.com/openai/codex/issues/13987) * Codex macOS sandbox prevents Playwright browser tests from starting (bootstrap_check_in Permission denied (1100), listen EPERM 127.0.0.1) #14368 _Powered by Codex Action_

No duplicate found.

The tool you're using likely needs some resource that is not available by policy in the sandbox. You'll need to determine what resource that is and configure the sandbox policy accordingly if you want it to run in the sandbox. Some tool maintainers have updated their tools to work better inside of agentic coding sandboxes. You might want to report the issue to the tool maintainer.

I'm experiencing the same problem. I'm using the codex vscode extension on windows and it cannot run flutter/dart commands without hanging indefinitely.
I end up having to run the commands myself and provide the outputs to codex.

I got around this by adding a context rule to codex. I have .agent/rules directory in my workspace (that I always reference with each new codex session) with a flutter_rules.md file where I added the following:

## Flutter and Dart Command Execution

In this Windows setup, `flutter` and `dart` commands should be run outside the sandbox.

Reason:

- the Flutter SDK lives outside the workspace under `C:\path\to\user\.flutter\flutter`
- Flutter startup needs access to SDK Git metadata and writes to the SDK cache under `bin\cache`
- sandboxed runs may hang or fail because that location is not fully accessible/writable inside the sandbox

Policy:

- do not tell the user to run routine `flutter` or `dart` commands manually just because they are outside the sandbox
- request an approval to run them outside the sandbox and execute them directly once approved
- when possible, use a persistent prefix approval for `flutter` and `dart`
- if permission has not yet been granted, trigger an approval request instead of stopping at instructions only

Codex will prompt me to allow running flutter and dart commands outside the sandbox for the first time and then I'll allow for the current session. With this It can run the flutter/dart commands without hanging.

I did not find a way to explicitly allow certain commands to run outside the sandbox and if possible it would be great to know how to do this.

As of now this is the solution I found with the help of Codex 😅

I’m seeing a similar issue on Windows in my multi-repo VS Code workspace with the Codex extension, where common Flutter/Dart commands can either hang indefinitely or fail inside the Codex sandbox.

Environment:

• Codex CLI: 0.142.0-alpha.6
• VS Code extension: openai.chatgpt-26.616.51431-win32-x64
• Windows: 10.0.26200
• Flutter: 3.44.2 stable
• Dart: 3.12.2
• Flutter SDK: <USERPROFILE>\flutter
• Codex config: [windows] sandbox = "elevated"

Inside the Codex Windows sandbox, bare Flutter command lookup is unreliable.

For example, flutter --version can fail with:

The term 'flutter' is not recognized as a name of a cmdlet, function, script file, or executable program.

This happens even though PATH contains <USERPROFILE>\flutter\bin.

The same command works in the normal VS Code terminal, and it also works when run outside the Codex sandbox. Inside the sandbox, absolute path execution works:

& <USERPROFILE>\flutter\bin\flutter.bat --version

flutter analyze --no-pub also works across multiple Flutter repos when invoked via absolute path and explicit working directory.

So this looks like an issue with Codex’s native Windows sandbox command resolution and/or .bat handling for Flutter tooling, rather than a broken Flutter install or repo-specific problem.

Before switching from unelevated to elevated sandbox, Flutter commands could often hang/no-response. After switching to elevated, the full hangs were harder to reproduce, but bare flutter lookups inside the sandbox are still unreliable.

Current workaround: use <USERPROFILE>\flutter\bin\flutter.bat directly, or a wrapper that resolves Flutter explicitly and kills the child process tree on timeout.

• Attempted debug and report summary generated with 5.5

I had success adding this modified version to the AGENTS.md on Windows 11.

## Flutter and Dart Command Execution

In this setup, the `flutter` and `dart` commands should be run outside the sandbox.

Reason:

- Flutter startup needs access to SDK Git metadata and writes to its own SDK cache.
- Sandboxed runs may hang or fail because that location is not fully accessible/writable inside the sandbox.

Policy:

- Do not tell the user to run routine `flutter` or `dart` commands manually just because they are outside the sandbox.
- Request an approval to run them outside the sandbox and execute them directly once approved.
- When possible, use a persistent prefix approval for `flutter` and `dart`.
- If permission has not yet been granted, trigger an approval request instead of stopping at instructions only.

I had success adding this modified version to the AGENTS.md on Windows 11. `` ## Flutter and Dart Command Execution In this setup, the flutter and dart commands should be run outside the sandbox. Reason: - Flutter startup needs access to SDK Git metadata and writes to its own SDK cache. - Sandboxed runs may hang or fail because that location is not fully accessible/writable inside the sandbox. Policy: - Do not tell the user to run routine flutter or dart commands manually just because they are outside the sandbox. - Request an approval to run them outside the sandbox and execute them directly once approved. - When possible, use a persistent prefix approval for flutter and dart. - If permission has not yet been granted, trigger an approval request instead of stopping at instructions only. ``

Thanks! It worked for me.