Rust compilation by codex results in hard-linking files across file systems
Open 💬 7 comments Opened Dec 31, 2025 by hweom
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.77.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2-codex
What platform is your computer?
Linux 5.15.197-1-MANJARO x86_64 unknown
What issue are you seeing?
When codex attempts to build even a simple Rust program, compiler complains about hard linking failures. In this example this is just a warning:
› Make this print "Hello all" instead of "Hello world". Then build and invoke it.
• Explored
└ List ls
Search Hello in src
Read main.rs
• Edited src/main.rs (+1 -1)
1 fn main() {
2 - println!("Hello, world!");
2 + println!("Hello all");
3 }
• Ran cargo build
└ Compiling link_test v0.1.0 (/home/mikhail/code/link_test)
warning: hard linking files in the incremental compilation cache failed. copying files instead. consider moving the cache directory to a file system which supports hard linking in session dir `/home/mikhail/code/link_test/target/debug/incremental/
… +2 lines
warning: `link_test` (bin "link_test") generated 1 warning
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
• Ran cargo run
└ warning: hard linking files in the incremental compilation cache failed. copying files instead. consider moving the cache directory to a file system which supports hard linking in session dir `/home/mikhail/code/link_test/target/debug/incremental/
link_test-14ijk4ciabvy6/s-heeghrr4y3-08ahhzm-working`
… +3 lines
Running `target/debug/link_test`
Hello all
─ Worked for 26s ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
• Updated the greeting in src/main.rs to print Hello all, then built and ran the binary.
Command output (invocation):
Hello all
Note: cargo emitted a warning about hard linking in the incremental cache; it still built and ran successfully.If I run this myself in a shell (or even in codex prompt with !) then it doesn't exhibit this behavior.
What steps can reproduce the bug?
Create a small Rust binary then run codex on it:
cargo new --bin link_test
cd link_test
codexAnd then give it the instructions above.
What is the expected behavior?
It can build without warnings.
Additional information
Mount points:
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8027244k,nr_inodes=2006811,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p2 on / type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=23587)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-journald.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=8044920k,nr_inodes=1048576,inode64)
/dev/nvme0n1p4 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1608980k,nr_inodes=402245,mode=700,uid=1000,gid=1000,inode64)
/dev/mapper/home-mikhail on /home/mikhail type ext4 (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
gdrive: on /home/mikhail/mnt/gdrive type fuse.rclone (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,allow_other)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)$ rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.90.0 (1159e78c4 2025-09-14)`
````$ rustc --version
rustc 1.90.0 (1159e78c4 2025-09-14)
7 Comments
The next time this happens, use the
/feedbackslash command to upload your logs (and optionally, session information) and paste the thread ID here. That information will allow us to investigate further.Since you're able to run these commands outside of codex, I suspect that it's related to the local sandbox mechanism codex uses to restrict the agent's file system writes. You can read more about the sandbox here.
The Codex CLI itself is written in Rust, so the codex team uses codex with the Rust toolchain every day. I'm not aware of any problems we've seen here, so we'll need to figure out what's different about your system and configuration that's causing the problem you're seeing. One obvious difference is that the codex team is using MacOS rather than Linux for local development work. That means we're exercising the MacOS sandbox implementation (based on Seatbelt) rather than the Linux implementation (based on Landlock). I tried your repro steps on my Mac, and I don't see any problems here. It's possible this is specific to Linux, but we haven't heard of a similar problem from other Linux codex users.
Do you have any other non-default configuration settings defined in your config.toml file?
Thanks, here's the feedback log: https://github.com/openai/codex/issues/new?template=2-bug-report.yml&steps=Uploaded%20thread:%20019b75b0-e618-7eb2-8859-33b18b945aae.
I don't think I have _any_ config.toml:
What's more interesting, if codex tries building first and gets hard link warning, then when I do
cargo buildin my separate terminal, I get the same warning:Curiously, when I try to
stracethe build it shows nothing:~/rustc-link.trace:I'm guessing that the rust toolchain hits a write failure due to the sandbox and has a fall-back code path that changes where it places its caches.
You could try doing your initial
cargo buildoutside of the sandbox. If my theory is correct, that will establish the caches and hardlinks. Then when you rebuild inside of the sandbox, it should work without issue.Building first doesn't seem to make a difference:
Somewhat unsurprisingly disabling the sandbox makes the issue go away:
I get the same problem.
me too