Codex 0.42.0 fails to run shell commands on AWS Lambda Python image (Operation not permitted (os error 1))

[omins]

What version of Codex is running?

codex-cli 0.42.0

Which model were you using?

gpt-5-codex

What platform is your computer?

Linux 5.10.240-263.966.amzn2.x86_64 x86_64 x86_64 (AWS Lambda base image: public.ecr.aws/lambda/python:3.12)

What steps can reproduce the bug?

1. Clone the reproduction repo.
2. Set up a Lambda function and ECR repository in the AWS console.
3. Deploy the function using the provided deploy-container.sh script (requires proper IAM roles).
4. Set the OPENAI_API_KEY environment variable for the Lambda function.
5. Invoke the function with the following request:

curl -X POST https://your-function-url.lambda-url.us-east-1.on.aws/api/codex/run \
  -H "Content-Type: application/json" \
  -d '{"query": "list all files in the current directory"}'

Full reproduction details are documented in the README.md

What is the expected behavior?

Codex should be able to execute shell commands inside the AWS Lambda container (same as on local environments).

What do you see instead?

Codex fails to run commands and returns Operation not permitted (os error 1) instead of executing them.

[2025-10-04T09:03:09] OpenAI Codex v0.42.0 (research preview)
--------
workdir: /var/task
model: gpt-5-codex
provider: openai
approval: never
sandbox: danger-full-access
reasoning effort: none
reasoning summaries: auto
--------
[2025-10-04T09:03:09] User instructions:
List all the directories in this repo
[2025-10-04T09:03:11] exec bash -lc 'find . -type d -print | sort' in /var/task
[2025-10-04T09:03:11] bash -lc 'find . -type d -print | sort' exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:11] tokens used: 2,652
[2025-10-04T09:03:12] tokens used: 2,652
[2025-10-04T09:03:13] exec bash -lc 'find . -type d -print 2>/dev/null | sort' in /var/task
[2025-10-04T09:03:13] bash -lc 'find . -type d -print 2>/dev/null | sort' exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:13] tokens used: 2,837
[2025-10-04T09:03:13] tokens used: 2,837
[2025-10-04T09:03:17] exec bash -lc \"python -c \\\"import os
seen=[]
for root, dirs, files in os.walk('.', topdown=True, onerror=lambda e: None):
    seen.append(os.path.relpath(root, '.'))
print('\\\
'.join(sorted(set(seen))))\\\"\" in /var/task
[2025-10-04T09:03:17] bash -lc \"python -c \\\"import os
seen=[]
for root, dirs, files in os.walk('.', topdown=True, onerror=lambda e: None):
    seen.append(os.path.relpath(root, '.'))
print('\\\
'.join(sorted(set(seen))))\\\"\" exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:17] tokens used: 3,394
[2025-10-04T09:03:18] tokens used: 3,394
[2025-10-04T09:03:21] exec bash -lc ls in /var/task
[2025-10-04T09:03:21] bash -lc ls exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:21] tokens used: 3,957
[2025-10-04T09:03:22] tokens used: 3,957
[2025-10-04T09:03:24] exec bash -lc pwd in /var/task
[2025-10-04T09:03:24] bash -lc pwd exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:24] tokens used: 4,214
[2025-10-04T09:03:24] tokens used: 4,214
[2025-10-04T09:03:30] exec bash -lc ls in /
[2025-10-04T09:03:30] bash -lc ls exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:30] tokens used: 4,917
[2025-10-04T09:03:30] tokens used: 4,917
[2025-10-04T09:03:32] exec bash -lc 'echo hello' in /var/task
[2025-10-04T09:03:32] bash -lc 'echo hello' exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:32] tokens used: 5,124
[2025-10-04T09:03:32] tokens used: 5,124
[2025-10-04T09:03:35] exec ls in /var/task
[2025-10-04T09:03:35] ls exited -1 in 0ms:
Operation not permitted (os error 1)
[2025-10-04T09:03:35] tokens used: 5,533
[2025-10-04T09:03:35] tokens used: 5,533
[2025-10-04T09:03:36] codex

I tried to inspect `/var/task` to enumerate the directories, but every command (`ls`, `find`, even a simple `echo`) fails immediately with `Operation not permitted`, so I can’t access the repository contents from this environment. If you can adjust the permissions or let me know an accessible path, I can try again.
[2025-10-04T09:03:37] tokens used: 10,555
"

Additional information

Use case
We’re integrating Codex as a tool for our internal AI agent, which reads our codebase and answers developer questions. We deployed Codex in an AWS Lambda container (python:3.12) so it can provide contextual answers based on the codebase. However, Codex can’t run shell commands inside Lambda, which blocks this use case entirely.

Latest version note
The issue template asks to confirm using the latest Codex CLI. We tried with 0.44.0, but couldn’t run Codex at all there because of a different prctl issue (codex#4679).

Related change
PR #1626 added logic to make sure child processes are terminated when their parent dies. That implementation uses prctl(PR_SET_PDEATHSIG), which seems to cause issues in restricted runtimes like AWS Lambda, where such syscalls aren’t allowed.

Hypothesis
It’s likely related to restricted syscalls in AWS Lambda’s Firecracker VM (e.g., prctl).

Workarounds

1. Adding a conditional guard around cmd.pre_exec() based on an environment variable allows Codex to start normally:

pub const CODEX_DISABLE_PRE_EXEC_PRCTL_ENV_VAR: &str = "CODEX_DISABLE_PRE_EXEC_PRCTL";

#[cfg(target_os = "linux")]
    unsafe {
        cmd.pre_exec(|| {
            if matches!(
                env::var(CODEX_DISABLE_PRE_EXEC_PRCTL_ENV_VAR).as_deref(),
                Ok("1")
            ) {
                return Ok(());
            }
            // This prctl call effectively requests, "deliver SIGTERM when my
            // current parent dies."
            if libc::prctl(libc::PR_SET_PDEATHSIG, libc::SIGTERM) == -1 {
                return Err(std::io::Error::last_os_error());
            }

            // Though if there was a race condition and this pre_exec() block is
            // run _after_ the parent (i.e., the Codex process) has already
            // exited, then the parent is the _init_ process (which will never
            // die), so we should just terminate the child process now.
            if libc::getppid() == 1 {
                libc::raise(libc::SIGTERM);
            }
            Ok(())
        });
    }

This skips the prctl(PR_SET_PDEATHSIG) call, which isn’t permitted in AWS Lambda.

2. Disable the sandbox
   Running Codex with --dangerously-bypass-approvals-and-sandbox avoids the secondary landlock / seccomp error:

thread 'main' panicked at linux-sandbox/src/linux_run_main.rs:28:9:
error running landlock: Sandbox(SeccompInstall(Prctl(Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" })))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Both workarounds together make Codex run successfully inside Lambda, but they’re not great long-term solutions.

Question
Is there a recommended or officially supported way to run Codex in restricted environments like AWS Lambda, where prctl, seccomp, and landlock are partially disabled?

I’d be happy to contribute or help test a more stable solution if there’s a path forward for serverless runtimes.