openai/codex-action

Codex uses various sources of context to perform tasks, but these can be used for prompt injection attacks. Treat the following sources as untrusted input:

• Pull requests: Specifically pull request bodies, which can hide malicious instructions in HTML comments (<!-- -->).
• Commit messages: Individual commit messages within a PR can be read by Codex.
• Repository instruction files: Files like AGENTS.md, AGENTS.override.md, or fallback project docs.
• Screenshots/Media: Images can be used as vehicles for injection.

To use Azure OpenAI instead of the default OpenAI endpoint, you must configure the responses-api-endpoint and openai-api-key inputs.

Requirements

• responses-api-endpoint: Must be the full URL including the v1/responses suffix (e.g., https://YOUR_RESOURCE.openai.azure.com/openai/v1/responses).
• openai-api-key: Must be a valid key compatible with the Authorization: Bearer <KEY> header for your Azure endpoint.

Example Configuration

- name: Start Codex proxy
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.AZURE_OPENAI_API_KEY }}
    responses-api-endpoint: "https://bolinfest-7804-resource.cognitiveservices.azure.com/openai/v1/responses"
    prompt: "Debug all the things."

To prevent shell injection, do not splice untrusted values (like branch names, issue titles, or PR comments) directly into a run: script using ${{ ... }} expressions. Instead, pass these values through the env: block and use quoted shell variables to consume them.

- name: Safe shell usage
  env:
    PR_BASE_REF: ${{ github.event.pull_request.base.ref }}
  run: |
    git fetch origin "$PR_BASE_REF"

By default, openai/codex-action only runs for users with write access to your repository. You can expand this list using specific inputs, but do so with caution:

• allow-users: A list of specific users allowed to run the workflow.
• allow-bots: Allows trusted GitHub bot actors (e.g., github-actions[bot]).
• allow-bot-users: A list of custom trusted bots. Note: This does not support the wildcard *; you must list each bot explicitly.

It is recommended to run openai/codex-action as the final step in a job, especially when using loose permissions. Because Codex can spawn background processes, overwrite source code of other actions, or modify configuration files (like .git/hooks), the state of the host is not guaranteed after Codex exits.

To maintain a clean workflow, consider taking the output of the action and passing it to a subsequent, fresh job.

The openai/codex-action allows you to run Codex from a GitHub Actions workflow with controlled privileges. It handles the installation of the Codex CLI and configures a secure proxy to the Responses API.

To use the action, you must provide an API key (e.g., OPENAI_API_KEY or AZURE_OPENAI_API_KEY) as a GitHub Actions secret.

- name: Run Codex
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt: "Your prompt here"

To ensure your OPENAI_API_KEY remains secret, you must use either drop-sudo or unprivileged-user as your safety-strategy.

Even if you use a read-only filesystem profile, the presence of passwordless sudo (the default on GitHub-hosted runners) can allow a process to access sensitive information via procfs. Using drop-sudo or unprivileged-user mitigates this risk.

You can provide the prompt to Codex in two ways using the PromptSource type:

• inline: Provide the prompt text directly via the content field.
• file: Provide a path to a file via the path field; the action will read the file contents.

// Inline prompt
const prompt = { type: 'inline', content: 'Write a hello world script' };

// File-based prompt
const prompt = { type: 'file', path: './prompts/task.txt' };

export type PromptSource =
  | { type: "inline"; content: string; }
  | { type: "file"; path: string; };

The Codex action uses SafetyStrategy and SandboxMode to control the level of access and risk during execution.

Safety Strategies

• drop-sudo: Default behavior.
• read-only: Forces the legacy read-only sandbox mode.
• unprivileged-user: Runs the command as a specific user via sudo -u <codexUser>. This is not supported on Windows and requires codexUser to be specified.
• unsafe: No restrictions.

Sandbox Modes

When using the sandbox permission type, you can choose from:

• read-only: Restricted access.
• workspace-write: Allows writing to the workspace.
• danger-full-access: Unrestricted access.

Note: permissionProfile and sandbox are mutually exclusive. You cannot combine a permission profile with legacy sandbox settings.