[Eduard van Valkenburg (eavanvalkenburg)]

Motivation & Context

Monty's post-execution file capture scans read-write mounts for new or modified files to return as attachments. On Windows, directory junctions and other reparse points are not always reported by Path.is_symlink(), so the host-side capture walker could traverse beyond the configured mount. This change keeps attachment capture limited to real regular files under the mount root.

Description & Review Guide

• What are the major changes? Reuse the core link/reparse-point predicate while walking Monty mounts, and read each captured file through one descriptor that is checked against the validated file (opened with O_NOFOLLOW where available) with every path component revalidated after opening. Add regression tests: real NTFS junctions on Windows, a portable junction model elsewhere, and swap-after-validation cases.
• What is the impact of these changes? Symlinks, junctions, and other reparse points are skipped during snapshots and post-run capture, and a file or ancestor swapped for a link after validation is skipped instead of read. Regular nested files, unchanged-file filtering, large-file omission, and virtual attachment paths retain their existing behavior.
• What do you want reviewers to focus on? The fail-closed path inspection and _read_validated_file. Windows has no no-follow open, so the read-time check narrows the replacement window rather than being kernel-atomic there.

Related Issue

N/A - no public issue. This is a narrowly scoped correction to host-side file capture, and no competing open pull request was found.

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Implementation, tests, design review, and this PR description.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

🟡 Changes recommended

Path validation remains vulnerable to a swap before read_bytes() reopens the file.

1 open finding

• Non-atomic path recheck allows symlink swap before read · New

What changed in this PR

Hardens Monty’s attachment capture against Windows reparse-point traversal.

Changes:

• Detects symlinks, junctions, and reparse points during capture.
• Adds fail-closed and Windows junction regression tests.

File	Description
_execute_code_tool.py	Adds secure-path validation during capture.
test_monty_codeact.py	Covers junctions, failures, and unchanged files.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (1 commit(s)): ad29dce3dd2d
Model: gpt-5.6-sol

Overview

This change strengthens Monty attachment capture by replacing symlink-only checks with the shared link/reparse-point predicate, classifying entries with lstat, and revalidating each path component before reading. The new tests cover Windows junctions created before and after the snapshot, fail-closed probe errors, unchanged files, and replacement detected by the second validation. The panel found residual path-open and aggregate-capture risks, but base-source comparison established that both predate this PR, so there is no publishable PR-introduced finding.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

[Jose Alvarez (jpalvarezl)]

Reviewed the complete change and surrounding mount/capture code. I found no additional issues beyond the existing unresolved atomic path-swap thread, which remains the blocker to approval.

[Eduard van Valkenburg (eavanvalkenburg)]

Jose Alvarez (@jpalvarezl) the atomic path-swap thread is addressed in 01911a7 (details and the remaining Windows limitation are in the thread), and all checks are green on the new commit. Thanks for the review.