fix(sandbox): scope exclusive Add File creation to UnixLocal

[ayaangazali]

This pull request fixes UnixLocal Add File overwriting an existing destination, including a file created concurrently after path resolution. Direct, wrapped and bound-user sessions claim the destination with exclusive creation while retaining supported parent symlinks and filesystem authorization. Other sandbox providers retain their existing normalized mkdir/write behavior.

If copying or closing fails after the destination is claimed, the SDK preserves the file and reports a non-retryable error with explicit inspect/update/remove recovery guidance. It does not require hard links or automatically delete a path that another operation may have replaced.

Regression tests cover concurrent creation, partial writes, close failures, replacement preservation and deliberate recovery across direct, wrapped and bound-user paths. The full formatting, lint, typecheck and test stack passes locally: 11,305 passed and 66 skipped. All 21 GitHub checks pass on 7f83445, including native macOS sandbox tests, Windows tests, Python 3.10–3.14, packaged compatibility contracts and CodeQL.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f36d84ba6b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[seratch]

The data-loss case is worth fixing, and the expected-error tracing change is correct. The remaining problem is that the absence check and write are separate operations. A concurrent sandbox command can create the file after the read, and the unconditional write then destroys that content. Reading also does not establish that a dangling symlink entry is absent. Please enforce create-if-absent at the backend write boundary, preserving the bound user and path policy, and cover an intervening creator whose contents must survive. Existing files should continue to use update_file.

[ayaangazali]

The two tests-windows failures were mine, and they are fixed in d68c465.

Root cause: the span assertion test I added needs FilesystemTestSandboxSession, which is typed to UnixLocalSandboxSessionState, and importing agents.sandbox.sandboxes.unix_local raises ImportError on Windows by design. tests/conftest.py already collect-ignores the other files that depend on it, including sandbox/test_session_sinks.py where I took the harness from, but sandbox/test_apply_patch.py should stay collectible on Windows because its other 25 tests are platform independent. So the narrow fix is a skipif on that one test, matching what test_posix_tool_paths.py and test_run_cwd.py already do with the same reason string.

The unix-only imports stay inside the test body on purpose. At module scope the skipif would not help, because collection itself would fail to import unix_local and take the whole file down on Windows.

Nothing in src/ changed for this, so the behaviour under review is the same as the commit you may have already looked at.

One thing I cannot confirm from my side: the workflow run for d68c465 is sitting at action_required, so it is waiting on maintainer approval rather than reporting. I am not going to push again to try to trigger it. Locally .agents/skills/code-change-verification/scripts/run.sh is clean and tests/sandbox/test_apply_patch.py is 25 passed.

[ayaangazali]

Done in 6ecc682. You were right that the probe was not good enough, and the dangling symlink half turned out to be sharper than I gave it credit for.

Where the enforcement moved. New BaseSandboxSession.write_new_file() claims the target name before the payload is written and raises FileExistsError when the name is already taken. The shared implementation runs a shell noclobber redirection, so set -C makes the redirect itself the O_EXCL attempt. UnixLocalSandboxSession overrides it with os.open(O_CREAT | O_EXCL) for its direct path and delegates to the shared version when a user is bound. apply_patch create_file calls it and no longer probes, which also removes the tracing workaround from the earlier commit since there is no probe read left to mark as expected.

Why a method rather than a flag on write(). All nine backends override write(). A new keyword there would need each one updated to honour it, and any backend that was not, including third-party ones, would silently accept exclusive=True and keep clobbering. With a base method that has a working shared implementation, a backend that does nothing inherits correct behaviour, and a backend with a cheaper native primitive can override. If you would rather have the flag, say so and I will convert it.

The symlink case was worse than a missing check. UnixLocalSandboxSession.normalize_path resolves symlinks, so validating the whole path turned a dangling link.txt into its absent target and the write landed on the target. My first attempt still had this, and the test caught it:

normalize_path(link.txt) -> /.../missing.txt
missing.txt exists now: True
missing.txt content:    b'clobbered'

Both paths now validate the parent through the normal policy, so grants, symlinked parents and the bound user are unchanged, and leave the final component unresolved. O_EXCL fails with EEXIST on a name held by a symlink, including a dangling one, so the link is rejected instead of followed.

Coverage. In tests/sandbox/test_unix_local.py: an intervening creator's content survives and the create is rejected, a dangling symlink is rejected without its target being created, parents are created for a nested path, the bound-user path maps exit 13 to FileExistsError without writing, and the bound-user path dispatches the unresolved link name rather than the resolved target. In tests/sandbox/test_apply_patch.py, a session that reports every path as missing on read() while still holding the file is still rejected, which pins the check to the write boundary rather than a probe. Six of the seven fail without the change.

I checked the shell recipe directly rather than assuming it: sh, bash and dash all return exit 13 for both an existing file and a dangling symlink, and 0 with parents created for a fresh nested path, with existing content untouched in the rejection cases.

Existing files still have to go through update_file. The branch is rebased onto current main and force pushed, so the earlier commits are the same work replayed.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6ecc68255e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ayaangazali]

All three are fixed in 72ede53, and two of them were real.

The wrapper bypass was the important one. SandboxSession did not forward write_new_file, so a session built by SandboxClient fell back to the shared implementation and never reached the UnixLocal os.open override. It forwards now.

The split write is gone. Instead of creating an empty file and then writing the payload, the payload goes to a staging name first and ln claims the target. ln fails when the name is already taken, so the content is complete before the name exists, and a failed or cancelled upload leaves only the staging entry, which is removed in a finally that cannot replace the outcome of the create.

The dash point was correct, and I had actually mis-tested it. I validated the recipe with cat > "$target" || exit 13, which returns 13 on dash because cat is a regular command, and then shipped : > "$target", which is a special builtin. Measured on this machine:

':' redirect    sh rc=13   bash rc=13   dash rc=2
'cat' redirect  sh rc=13   bash rc=13   dash rc=13

So a collision on dash surfaced as WorkspaceArchiveWriteError and WorkspaceEditor could not convert it into the actionable ApplyPatchDiffError. My unit tests could not catch this because they stub _exec_internal and never run a shell. There is now a test that runs the shipped script constant through sh, dash and bash and asserts 13 for both an existing file and a dangling symlink and 0 with the full payload for a fresh nested path. I confirmed it fails if the : version is restored.

The umask point is right too. os.open(..., 0o644) narrowed the mode compared with Path.open("wb"), which creates 0o666 & ~umask. Under a collaborative umask that would have made Add File produce 0644 where the ordinary write path produces 0664. It passes 0o666 now and lets the umask decide.

Full stack is clean locally.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 72ede535aa

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ayaangazali]

Fixed in 3356606. The leaf-resolution one was the real defect and it was live through the actual tool path, not just theoretical.

Preserving the leaf name. WorkspaceEditor.apply_operation normalizes destination before dispatching, and UnixLocalSandboxSession.normalize_path resolves leaf symlinks, so my primitive was handed the link target. Reproduced through session.apply_patch() on main plus my previous commit:

RESULT: 'Done!'
missing.txt created: True
dir listing: ['link.txt', 'missing.txt']

The create path now passes the unresolved path. My earlier symlink test called write_new_file directly, which is exactly why it passed while the real path was broken, so the new tests drive session.apply_patch() instead. Reverting only the apply_patch.py change makes the dangling-symlink test fail again.

The directory case. Bare ln treats an existing directory as a target directory and links the staging file inside it, so the create reported success and left a hidden payload. The script now rejects a name held by a directory before linking. Locally this was already correct, but the shared path serves the remote backends, so it mattered there.

Local staging. The Unix-local override claimed the name with os.open and then copied, so a write that failed partway left an empty file holding the name and a retry got FileExistsError. It stages the payload and then os.links it into place, matching the shared path. os.link fails with EEXIST for a file, a directory or a dangling symlink, which also let me drop the O_NOFOLLOW and ELOOP special-casing.

Staging cleanup and parent ownership. The staging write moved inside the cleanup scope so a failed or cancelled upload cannot leak .name.create-<uuid> into the workspace or a later snapshot. The parent is now created as the bound user before staging, so a fresh nested path is owned the way the previous _write_text path owned it.

The : comment appears to be a repost of the earlier finding; that redirection is gone, and ln is a regular command. The parametrized test that runs the shipped script through sh, dash and bash now also covers the existing-directory case.

Full stack clean locally. I am conscious this diff has grown well past where it started. If you would rather have the primitive landed on its own, or scoped to UnixLocal only with the remote backends following separately, say the word and I will split it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3356606ee8

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Security Review

Here are some automated security review suggestions for this pull request.

Reviewed commit: 3356606ee8

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[ayaangazali]

Two of these were live and are fixed in 4ebc93c. Three are reposts of findings already addressed in 3356606. One is a blocker I do not think I should decide alone.

Fixed: the login shell. I had used sh -lc. This path runs for a filesystem-only capability set, so sourcing shell startup files that live in the workspace being edited is the wrong default for a primitive whose whole job is a single guarded create. It is sh -c now.

Fixed: collision classification. A parent that is a regular file makes mkdir raise FileExistsError, and my broad handler reported that as a collision on the requested name, so the model would be told to use update_file for a target that does not exist. Only the os.link call can report a collision now, and parent or staging failures are wrapped as write errors. Covered by a test through session.apply_patch().

Already addressed in the previous commit: the : redirection is gone, the script rejects a name held by a directory before linking (if [ -e "$target" ] || [ -L "$target" ]; then exit 13; fi, covered for sh, dash and bash including the directory case), and the parent is created with await self.mkdir(parent_path, parents=True, user=user) before staging.

The blocker: hard links. The object-storage mount point is correct and it breaks the shared implementation rather than needing another condition. A writable rclone, Mountpoint or Blobfuse destination does not provide POSIX hard links, so ln fails, cleanup removes the staging file, and Add File on a fresh mounted path returns a write error where the previous direct write() succeeded. That is a regression of working behaviour, not an edge case.

I do not think I can fix that generically. exec() has no stdin, so the shared implementation cannot stream a payload through the shell in one step. That leaves two shapes, and both are already ruled out: create empty then write, which you and Codex correctly rejected because a concurrent writer is overwritten and a failed upload leaves an empty file holding the name; or link a staged file, which needs hard links. A generic exclusive create that works on every supported mount really does need a per-backend primitive.

So the honest position is that the shared shell implementation should go, and enforcement should be backend-native. UnixLocal has one that works. The other seven backends need their own, and I cannot write or meaningfully test those.

How would you like to proceed?

1. Scope this PR to UnixLocal: keep the native os.link primitive and the apply_patch wiring, drop the shared shell implementation, and let each remaining backend adopt the primitive in its own change. The data loss you called worth fixing is fixed where it can be verified, and nothing regresses.
2. Close this and take the design in-house, the way you did with fix(sandbox): terminate UnixLocal execs on cancellation #4723. The reproduction, the caller-path tests and the reasoning above are all here to reuse.

I am happy either way, and I would rather close it than keep adding conditions to a shape that cannot hold. Four review rounds is past the point where I should be choosing the scope myself.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4ebc93ca86

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[fscfede-beep]

Rumbo follow-up: PR #4930 hardens this implementation for two current P2 findings — fixed-length staging basenames and early observable-target collision classification, while retaining the atomic claim for races. #4930 is intentionally based on this PR rather than presenting the work as unrelated.

[ayaangazali]

Thanks for flagging #4930, and for basing it on this branch openly instead of presenting the work as unrelated.

On the two findings:

Fixed-length staging basename is real, and it is my regression. The staging name is .{name}.create-{uuid4().hex}, which adds 41 characters, so a destination that is valid under a 255 byte component limit can push the staging name past it. Reproduced on my current head: a 254 character filename that a plain write accepts fails create_file with WorkspaceArchiveWriteError, and the same name worked before this PR because the old path wrote straight to the destination. Agreed, and it needs fixing.

Early collision classification I read as an improvement rather than a correctness bug. Today the payload is staged before the collision is detected, so Add File onto an existing name uploads bytes that are then discarded, which is wasteful on remote backends. That seems right to do, as long as the preflight stays additive and the atomic claim is still what decides races, which is what your description says.

One practical note: #4930 shows as closed, opened 11:49:38Z and closed 11:54:17Z, so as things stand neither fix has a home. I would rather not absorb your work. If you reopen it or push a replacement, I will leave both to you and keep this branch as the base. If you would rather not carry it, say so and I will fold the staging-name fix in here with credit to you.

For whoever picks this up: there is an open question further up this thread about whether the shared shell implementation should exist at all, because hard links are not available on writable object-storage mounts. Both of these findings apply to that shared path, so the answer to that one probably decides where they land.

The branch is rebased onto current main and the full local stack is clean.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9820c3fa1e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ayaangazali]

@fscfede-beep I said a few hours ago that I would leave both fixes to you, and I have gone back on half of that. Explaining rather than doing it quietly.

I fixed the staging basename in 8049c24. The reasoning: #4930 is closed, so there is nothing for the fix to stack on, and this is a regression I introduced in this branch rather than a general improvement, so leaving it sitting in an open PR while waiting was the wrong call. The staging basename is now constant at 52 characters instead of being derived from the destination. There is a regression test using a 254 character name that first confirms the platform accepts that name, so it fails for the right reason, and it fails without the fix with the same WorkspaceArchiveWriteError you predicted.

Finding credit is yours and it is in the commit message.

Your second point, preflighting an observable target before staging payload bytes, I have deliberately not touched. That one is an improvement rather than a fix to something I broke, and it is yours to land if you reopen. If you would rather I carried it too, say so and I will.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8049c24122

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ayaangazali]

Status after working every open review thread.

Fixed and resolved

• sh -lc to sh -c, so the exclusive create no longer sources workspace-writable shell startup files (4ebc93c).
• Fixed-length staging basename, so a valid long destination no longer fails to stage (8049c24). This was a regression I introduced, not a pre-existing limit.
• A visible collision is now classified before any payload is staged, in both the shared path and the Unix-local override (bd47f64). A target inside a 0555 parent used to surface WorkspaceArchiveWriteError; it now surfaces ApplyPatchDiffError pointing at update_file. The atomic claim still decides real races, and a creator that wins between the probe and the link still loses the name with its staging entry cleaned up.

Answered and left open on purpose

Two threads describe the shared hard-link implementation failing on supported configurations rather than missing a condition: run_as against a backend that uploads as the provider identity cannot hard-link across owners under fs.protected_hardlinks=1, and writable rclone, Mountpoint and Blobfuse mounts have no POSIX hard links at all. Because exec() has no stdin, the shared path cannot stream a payload and claim a name in one step, and the alternative of create-empty-then-write was already rejected here.

@seratch the behaviour you asked for is implemented and covered: the name is claimed at the backend write boundary, an intervening creator keeps its content, and a dangling symlink at the target name is rejected rather than followed. What I cannot settle myself is scope. Either this lands scoped to the UnixLocal primitive, which is the one I can actually verify, with each remaining backend adopting its own later, or the shared shell path comes out and the design goes to you. I would rather stop hardening a path that may be removed. Happy with either, including closing this in favour of a maintainer-owned version.

Branch is rebased on current main, zero commits behind. Local stack clean; every affected test file passes. Checks show none because the workflow run is at action_required, the approval gate, so there is nothing red to chase.

[ayaangazali]

#4931 landed and I think it answers the scope question I asked above, so flagging it rather than quietly rebasing.

That change gives UnixLocal a dir_fd plus O_NOFOLLOW file-ops layer, and routes the bound-user path through a Python worker running that same module (_USER_FILE_WORKER_SOURCE = inspect.getsource(_unix_local_file_ops)) instead of a shell. The no-user path goes through self._files.write(...). Both ends now have a symlink-safe primitive that operates on a directory descriptor and a leaf name.

That is the primitive this PR was missing, and it is better than what I built. Exclusive create becomes an O_EXCL variant of the existing open in that module, where today it is O_WRONLY | O_CREAT | O_TRUNC | O_NOFOLLOW. One flag, atomic in the syscall, identical on the no-user and bound-user paths.

Doing it that way removes the machinery the open threads are about, rather than hardening it:

• no ln, so cross-owner hard links under run_as with fs.protected_hardlinks=1 stop mattering, and so do writable object-storage mounts with no hard links at all;
• no staging entry, so there is nothing for a concurrent tool to replace and nothing to clean up;
• no shell for the local path at all, so the startup-file concern does not arise;
• my parent-normalize plus unresolved-leaf workaround goes away, because dir_fd plus O_NOFOLLOW is the real version of what I was approximating.

My branch still merges cleanly onto current main, but merging cleanly is not the same as being the right shape, and keeping a second mechanism next to the new one is the duplicate-lifecycle problem you raised when closing #4892.

So my proposal, if you agree: I rewrite the UnixLocal side on _unix_local_file_ops with O_EXCL, drop the shared shell implementation and the write_new_file staging path entirely, and this PR becomes UnixLocal-only with the remaining backends adopting their own primitive separately. That is the first of the two options I offered, now with a much smaller diff. Tell me if you would rather own it yourself and I will stand down.

Nothing pushed for this; it is a design note. I have not rebased because I would rather agree the shape first than resolve a rework of the same file twice.

[ayaangazali]

Rebuilt on #4931 as proposed, in 93cb1b3. Net effect is 135 insertions against 326 deletions, so this is mostly removal.

What it does now. write_new in _unix_local_file_ops is the existing write with O_TRUNC replaced by O_EXCL. It claims the name in the same syscall that creates the file and fails with EEXIST when the name is taken by a file, a directory, or a dangling symlink, and the surrounding dir_fd plus O_NOFOLLOW handling is yours, not mine. The bound-user path runs the same module in the worker and exits with a distinct status for an existing target so the caller reports FileExistsError instead of a generic write error.

What it deletes. The shell script, the staging file, the hard link, and the staging cleanup. That removes the causes behind the two threads I left open rather than adding conditions to them: with no hard link there is nothing to fail on writable object-storage mounts or across owners under fs.protected_hardlinks, and with no staging entry there is nothing for concurrent work to observe or replace. My parent-normalize plus unresolved-leaf workaround is gone too, since the file ops already do that properly.

The shared base now documents what it actually guarantees: it rejects an occupied target and leaves the existing content alone, it is explicitly not atomic, and a backend that can claim a name should override it. If you want a guaranteed claim on every backend, that is per-backend work I cannot verify for the provider adapters, and I would rather you scope it than have me guess.

One thing you should look at. test_parent_swap_after_validation_cannot_access_outside[patch] injected its swap at session.normalize_path, which the create path no longer calls, so the swap stopped firing and the case was passing for the wrong reason. I re-pointed the patch case at the _files.authorize boundary the create path does traverse, so the injection fires again and the test still asserts swapped. I checked the property independently first rather than assuming: with a parent symlinked outside the workspace, the create is refused with InvalidManifestPathError and the outside file keeps its original bytes. Editing a security test of yours is not something I wanted to do quietly, so please sanity-check that hunk.

Verification, stated precisely. Affected files all pass: test_unix_local_file_io.py 24, test_unix_local_user_file_io.py 20, test_unix_local.py 27, test_apply_patch.py 25, capabilities/test_apply_patch_tool.py 25, test_apply_patch_tool.py 11. Lint clean. I have not re-run the whole suite since the fix because this machine is under a memory limit right now, so I am not claiming a full green; the only failure the last full run produced is the one described above and it is fixed.

Branch is rebased on main at 0.22.2.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 93cb1b3046

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 304545645f

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ayaangazali]

@seratch this is ready for another look when you have time. Every review thread is resolved, and the shape changed enough since your review that a re-read is probably cheaper than following the thread history.

Where it landed. Exclusive create is now write_new in _unix_local_file_ops, which is your existing write with O_TRUNC replaced by O_EXCL. It claims the name in the syscall that creates the file and fails with EEXIST for a file, a directory, or a dangling symlink. The bound-user path runs the same module in your worker and returns a distinct status for an existing target. Your dir_fd plus O_NOFOLLOW handling from #4931 does the symlink work; I just added the flag variant and wired it.

That deleted the shell script, the staging file, the hard link, and the staging cleanup that my earlier attempts needed. The two findings I had left open, cross-owner hard links under run_as and ownership-safe staging cleanup, are gone with the mechanism rather than patched around.

Source side is 153 lines across four files: 31 in _unix_local_file_ops.py, 58 in unix_local.py, 39 in base_sandbox_session.py, 13 forwarding in sandbox_session.py, and 25 in apply_patch.py. The rest is tests.

The behaviour you asked for is covered: the name is claimed at the backend write boundary, an intervening creator keeps its content, and a dangling symlink at the target name is rejected rather than followed.

Two things I would rather you decided than me.

The shared base default rejects an occupied target but is explicitly not atomic, and its docstring says so. Backends that can claim a name should override it, as UnixLocal now does. If you want a guaranteed claim on every provider adapter, that is per-backend work I cannot verify, and I would rather you scoped it than have me guess.

I edited one of your tests. test_parent_swap_after_validation_cannot_access_outside[patch] injected at session.normalize_path, which the create path no longer calls, so its swap stopped firing and the case was passing for the wrong reason. I re-pointed the patch case at the _files.authorize boundary the create path does traverse. I verified the property independently first: with a parent symlinked outside the workspace the create is refused with InvalidManifestPathError and the outside file keeps its bytes. Please sanity-check that hunk.

CI still shows nothing because the workflow run sits at action_required. Locally the affected files are green and lint is clean.

[github-actions]

This PR is stale because it has been open for 10 days with no activity.

[jbeckwith-oai]

@seratch The requested create-if-absent behavior is now enforced at the UnixLocal write boundary, with bound-user and path-policy handling preserved. Controlled concurrent-creator tests verify that the intervening file survives through direct, wrapped and bound-user sessions. The generic probe has been removed; the PR explicitly limits the exclusive-create guarantee to UnixLocal and preserves other providers’ existing behavior.

For failures after claiming the destination, the maintainer-selected contract preserves filesystem compatibility and reports a non-retryable partial-write error with explicit inspection/recovery guidance. Tests cover copy and close failures, concurrent replacement preservation and deliberate recovery.

Merged current main to resolve the test conflict. All 21 GitHub checks pass on 5479144, including native macOS and Windows tests. The complete local verification stack passed with 11,299 tests, and both independent authority/lifecycle reviews are clean. Existing feedback threads are resolved and the affected threads now include implementation details. Ready for re-review.

[markstuart-oai]

Reviewed all 12 changed files at 5479144, including the direct, wrapped and bound-user create paths, prior feedback, and the surrounding path/worker contracts. No blocking correctness or structural findings.

The private backend hook keeps UnixLocal’s exclusive claim and payload on the same descriptor while preserving other providers’ normalized mkdir/write behavior. Parent symlinks remain supported without resolving away the requested leaf. Post-claim copy/close failures retain the destination and report non-retryable inspection/recovery guidance, avoiding unsafe pathname cleanup. The focused regressions cover concurrent creators, dangling links, partial writes, replacement preservation and explicit recovery.

All 21 hosted checks passed on this exact commit, including Windows and native macOS. This was a source review; I did not run repository workloads or independently exercise live sudo/provider environments.

[jbeckwith-oai]

Resolved the latest main merge conflict in 7f83445, retaining both the new UnixLocal snapshot imports/tests and this PR’s apply-patch imports/tests. Both independent integration reviews are clean. The full local verification stack passed with 11,305 tests, and all 21 GitHub checks pass on the pushed commit, including Windows and native macOS. The PR is mergeable and ready for the requested maintainer re-review.

[jbeckwith-oai]

Maintainer decision: need demonstrated; merge-worthy as-is for the stated UnixLocal scope. Repository readiness: CI or review pending.

Reviewed the complete 12-file diff at 7f83445, from merge base 99f8d77 against current main, including surrounding caller paths and previous review discussion.

The underlying problem merits an SDK fix: in v0.22.3 and the base implementation, Add File reaches the ordinary truncating write, so an existing file—or a file created by another operation before the write—can lose its contents while the operation reports success. A separate existence check cannot guarantee create-if-absent. Existing update_file and write remain the supported choices for intentional overwrites; they do not solve this safety requirement.

The current implementation puts the claim at the right boundary. UnixLocal uses O_EXCL and writes through the claimed descriptor, including through SandboxSession and the bound-user worker. Supported parent symlinks, write authorization, nested parents and umask semantics remain intact. Copy/close failures preserve the destination and report non-retryable inspection/recovery guidance, with no pathname cleanup that could delete another operation’s replacement. Other providers retain their normalized mkdir/write behavior without a new exec or hard-link requirement. This is a proportionate fix; generic provider atomic creation or transactional staging would be separate work.

No actionable defects found after two clean rounds, each with two independent fresh-context reviewers covering correctness/security and architecture/ownership. The inspected regressions exercise intervening creators, dangling leaf links, partial writes, close failures, replacement preservation, explicit recovery and scripted-provider compatibility. The earlier findings addressed by removed probes/staging or the current forwarding/recovery implementation are not repeated here. Bounded duplicate searches found no competing open implementation; #4930 is closed, and #4890 addresses update/rename rather than Add File.

Validation limits: source and test inspection only; no PR code, tests, imports or runtime probes were executed for this review. All 21 hosted checks report success on this exact head, including Windows and native macOS. Live sudo identities and external provider environments were not independently exercised.

Next action: maintainer re-review of this head to resolve the outstanding changes-requested review. GitHub reports the PR mergeable but still blocked by review state. This assessment requests no additional code changes.