HN Debrief

A way to exclude sensitive files issue still open for OpenAI Codex

  • AI
  • Security
  • Developer Tools
  • Infrastructure

The linked GitHub issue complains that Codex still does not support a reliable way to keep sensitive files out of scope, especially secrets sitting near source code in files like .env.local. That sounds like a missing convenience feature, but the useful conclusion is harsher: an ignore file is not a security boundary for a tool that can run shell commands, grep through trees, invoke build steps, and ship tool output back to a remote model provider. If the agent can access a file at all, it can usually find some path to expose it, whether by direct reads, search output, logs, or side effects from other tools. Several people pointed out that this is already how Codex works in practice. The model only “sees” what gets sent to OpenAI, so anything the harness feeds it is already exfiltration risk.

If you use cloud coding agents on a workstation that also holds secrets, move from ad hoc ignore rules to explicit isolation now. Give agents a task-scoped workspace, narrow credentials, and no access to anything you would not hand to an untrusted contractor shelling into the same machine.

Discussion mood

Skeptical and security-minded. Most commenters think the issue is real but misframed, and they are frustrated that people expect an ignore file to solve a host isolation problem. The mood also carries distrust of cloud agent vendors, both because the products are marketed as turnkey and because any feature that looks like secret protection but fails at the edges creates dangerous false assurance.

Key insights

  1. 01

    Harness-layer redaction can still help

    Adding deterministic filters between tool output and the model can catch a meaningful class of leaks even if it cannot guarantee perfect secrecy. One example was redacting strings that match known secret material or look like high-entropy credentials before stdout or file output is forwarded upstream. That does not replace sandboxing, but it shrinks the blast radius for accidental prompt and tool-output leaks.

    Add an output-inspection layer even if you already sandbox. Scan prompts, logs, grep results, and tool stdout for secrets before they leave the machine.

      Attribution:
    • chriddyp #1
  2. 02

    Codex is already close to enforceable sandboxing

    Several detailed comments pushed back on the idea that only separate users or full VMs can solve this. Codex already runs many commands under Bubblewrap or platform sandboxes, and one commenter described a local patch that forces every built-in tool and escalated command through one unified sandbox policy with hard filesystem deny rules. The key point is that the security boundary should wrap the tools, not depend on the agent voluntarily obeying an ignore list.

    If you run Codex seriously, inspect whether all tool paths are covered by the same sandbox policy. Gaps between shell commands, built-in read tools, and escalation paths are where leaks happen.

  3. 03

    Opt-in workspaces beat opt-out file blocking

    A cleaner operating model is to start from an empty isolated workspace and copy in only the code and credentials needed for that task. That flips the default from “agent can see my machine unless I remember to exclude things” to “agent sees nothing unless I deliberately provide it.” This also simplifies user experience because the safe path is the default session creation flow, not an expert-only hardening step.

    Design internal agent tooling around disposable workspaces, not direct access to developer laptops. Make session setup the place where scope is chosen and enforced.

      Attribution:
    • nikhilsimha #1
  4. 04

    The .env habit is part of the problem

    A lot of the risk comes from normalizing secrets as files living right next to code. Commenters argued for separating code from data, moving configs outside the working tree with conventions like XDG_CONFIG_HOME, and using brokered access such as ssh-agent style proxies instead of raw bearer tokens in env files. If the secret is never in the repo-adjacent filesystem view, the agent has much less to steal.

    Audit your dev setup for repo-local secrets first. Moving credentials out of the project directory is often easier and more durable than trying to teach every agent not to read them.

      Attribution:
    • skybrian #1
    • pamcake #1
    • tiew9Vii #1
  5. 05

    A tooling ecosystem is forming around isolation

    This was not just abstract advice. People shared concrete tools for running agents in isolated devcontainers, Linux sandboxes, macOS sandboxes, Apptainer, and lightweight VMs like smolvm. The shape of the market is becoming clear. Agent adoption is creating demand for disposable execution environments that can review diffs, merge changes back, and keep the local machine out of scope.

    Expect agent-safe workspaces to become standard developer infrastructure. If your team is adopting coding agents, evaluate sandbox and workspace tooling now instead of treating it as an edge-case add-on.

      Attribution:
    • mbid #1
    • kstenerud #1 #2
    • kardos #1

Against the grain

  1. 01

    Unix permissions may be enough for many users

    A strong minority view held that this is mostly user error dressed up as a product bug. If the Codex process cannot read a file, it cannot leak it, and ordinary file permissions or a separate user already solve that without adding a misleading in-app feature. From that angle, asking Codex for a secure ignore list puts the boundary at the wrong layer and encourages unsafe habits.

    If your workflow is simple, start with the boring controls before building heavier isolation. A separate user and tighter permissions are cheap and may cover most personal use cases.

      Attribution:
    • TheDong #1
    • cowsandmilk #1
    • petcat #1
    • planb #1
    • pamcake #1
  2. 02

    Vendors are not eager to limit data flow

    Some commenters argued that the missing feature is not just an engineering gap but a business incentive problem. Coding agents double as data collection channels for model improvement, so strong local controls that reduce what reaches the provider are not naturally aligned with vendor interests. That framing explains why users should not wait for first-party safety features to become the real boundary.

    Assume provider defaults optimize for product utility, not your minimum data exposure. Put your own guardrails in front of any hosted model if the inputs matter.

      Attribution:
    • nicce #1
    • kennethops #1

In plain english

.env ↩
A configuration file that stores environment variables, often including API keys, database credentials, and other secrets.
Apptainer ↩
A container platform often used in research and high performance computing to run isolated software environments.
Bubblewrap ↩
A Linux sandboxing tool that isolates processes from parts of the filesystem and system resources.
Codex ↩
OpenAI’s coding agent and command-line tooling that can read files, run commands, and send context to a remote language model.
devcontainer ↩
A development environment packaged in a container with the tools and dependencies needed for a project.
grep ↩
A command-line search tool used to find lines that match a text pattern in files.
Seatbelt ↩
Apple’s macOS sandboxing system for limiting what files and resources an app can access.
seccomp ↩
Secure computing mode, a Linux kernel feature that restricts which system calls a process can make.
ssh-agent ↩
A background program that holds SSH private keys and lets other programs use them without exposing the raw key material.
stdout ↩
Standard output, the normal text stream a program writes as its output.
XDG_CONFIG_HOME ↩
A standard directory location on Unix-like systems for storing user-specific application configuration files outside the project folder.

Reference links

Issue and prior discussion

Sandbox and workspace tools

  • rumpelpod
    Open source tool for orchestrating agents inside remote or secure devcontainers.
  • yoloai
    Sandbox workflow for running agents in isolated environments and reviewing diffs before applying changes.
  • drop
    Linux sandbox aimed at hiding sensitive files from AI agents while keeping needed files accessible.
  • sandfence
    macOS sandbox setup for giving agents access only to selected folders and repositories.
  • smolvm
    Lightweight virtual machine project built for isolated agent workspaces.
  • smol-pi
    Wrapper around smolvm for ephemeral VMs with configurable network isolation.
  • Claude governance integration from Tenuo
    Example of task-scoped authorization and governance for coding agents.

Sandboxing references

Related products and standards

  • greywall.io
    Mentioned as a lower-friction containment layer between agent runtimes and the host environment.
  • multitui.com
    Referenced as a macOS app for sandboxing Codex and blocking file access.

Background references