macOS sandbox: Turbopack next build completes work but does not exit, leaving .next/lock open

Resolved 💬 3 comments Opened Apr 21, 2026 by ohcedar Closed Aug 4, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4

What platform is your computer?

macOS 26.4.1 (Build 25E253), Darwin 25.4.0, arm64

What terminal emulator and version are you using (if applicable)?

Codex in VS Code / extension-host environment on macOS

What issue are you seeing?

In the Codex macOS sandbox, next build for a Next.js 16.2.0 app using Turbopack appears to complete the build work but the process does not exit cleanly.

Observed behavior inside Codex:

npm run build reaches Creating an optimized production build ...
the process then remains alive in sleep state with ~0% CPU instead of exiting
the process keeps .next/lock open
a subsequent build reports Another next build process is already running.
if I kill the stuck build and rerun with webpack instead of Turbopack, the build exits normally

Important detail: Next's own trace output indicates the build work actually finished. In .next/trace-build, next-build completed in about 9 seconds, including static generation and trace collection. The hang appears to be in process teardown / exit, not compilation.

The same project builds successfully outside Codex on the same machine, so this looks environment-specific to the Codex macOS sandbox rather than an application bug.

What steps can reproduce the bug?

Use Codex on macOS in the default sandboxed environment.
Open any Next.js 16.2.0 app that uses the default Turbopack production build.
Run npm run build.
Wait for the build to reach Creating an optimized production build ....
Observe that the process remains alive after the build artifacts and .next/trace-build indicate completion.
Attempt a second build and observe Another next build process is already running.

What is the expected behavior?

After the build work completes, next build should exit normally.

Additional information

Relevant environment details observed from inside Codex:

CODEX_SANDBOX=seatbelt
CODEX_SANDBOX_NETWORK_DISABLED=1
TERM=dumb
ELECTRON_RUN_AS_NODE=1

What I tested:

unsetting the CODEX_* environment variables did not fix the hang in this environment
NEXT_TELEMETRY_DISABLED=1 npm run build still hung
npm exec next build -- --webpack completed successfully and exited normally
lsof -p <pid> for the hung process showed .next/lock still open and no child processes remaining

This makes Turbopack + Codex macOS sandbox teardown the most likely problem area.

View original on GitHub ↗

3 Comments

karlhorky · 28 days ago

@gaojude @sampoder should this be reported + fixed within Next.js? Do you know why next build hangs inside Codex CLI by default?

I've been encountering this for a while and I thought it was the fault of Codex, but maybe it should be fixed in Next.js?

For our app, it also appears to only affect Turbopack, not webpack.

---

For now I'm doing this hacky thing to exit in my scripts if next build is being run inside the agent sandbox:

// Fail fast in AI agent sandboxes to avoid hanging in next build
// - https://github.com/openai/codex/issues/18895#issuecomment-5132506377
if (process.env.CODEX_CI || process.env.CLAUDECODE) {
  await new Promise<void>((resolve, reject) => {
    const server = createServer();
    server.once('error', (error) => {
      reject(
        new Error(
          'AI agent sandbox detected - run `next build` outside the sandbox',
          { cause: error },
        ),
      );
    });
    server.listen(0, '127.0.0.1', () => {
      server.close(() => resolve());
    });
  });
}

sampoder · 28 days ago

Hi @karlhorky & @ohcedar! Thanks for sharing! This appears to be an issue with Webpack loaders in Turbopack and Codex's not allowing local binding by default (which we depend on). You can fix this by configuring allow_local_binding to be true in your Codex configuration: https://learn.chatgpt.com/docs/permissions#local-and-private-networks.

If you would like to not enable that by default, you can prompt your agent to ask for one-time permission when using next build

Alternatively, with newer versions of Next.js / Turbopack we have fixed issues with this experimental worker threads option for loaders:

experimental: {
  turbopackPluginRuntimeStrategy: 'workerThreads',
}

See https://github.com/vercel/next.js/pull/95281. You can use that to work around this limitation! However, in older versions, I wouldn't recommend this option as there used to be a memory safety bug.

etraut-openai contributor · 24 days ago

Enabling allow_local_binding or using the newer runtime resolves the Turbopack hang.