fix(filesystem): bound reads and watches without breaking linked files

[Raghav-Bansal-15]

Directory scans could follow a root alias into a path rejected by the service’s blocked-path policy.

Reapply that policy to the resolved scan root before traversal. Preserve bounded scan/watch/read behavior and reviewer ARM64 coverage. Make symlink-fixture teardown no-follow and unlink the external alias in finally.

Validation at 8409e803: 32 filesystem tests passed, one platform skip; ktlint/detekt pass. The alias-refusal regression fails on the previous implementation and passes after the fix. Current-head hosted CI passed; the previous head’s macOS build failed during Temurin signature download with HTTP 500, before tests.

Original and reviewer commits are preserved. Upstream approval remains separate; no merge or release.

Hosted validation: all current-head fork workflows passed at 8409e803: 🔨 Build & Test, Filesystem resource limits. Upstream approvals and the stated non-CI gates remain separate.

[kshivang]

@claude review Please review the current filesystem resource-limit changes, paging behavior, and watch cleanup for correctness.

[claude]

Claude finished @kshivang's task in 8m 47s —— View job

---

Review: filesystem resource limits, paging, watch cleanup

• Read the PR diff (git diff b39c756..HEAD, 12 files)
• Review RegularFileReader paging / 64-bit offsets
• Review BoundedDirectoryScan limits
• Review FileWatchRegistry cleanup and subscriber limits
• Review proxy paging assembly + proto change
• Review tests and CI workflow
• Post findings

The paging half is careful and fixes a real bug (offsetBytes.toInt() silently truncated 64-bit offsets, and file.readBytes() read the whole file into heap before slicing). The scan/watch half converts every ceiling into a hard failure of the whole operation, and both walkers now re-throw on the most common real-world I/O error, which I think is the main thing to resolve before merge.

---

High - the ceilings make recursive scan and watch unusable on a real project

FileWatchRegistry.Registrations.add counts every entry, files included, against SCAN_ENTRIES = 10_000 and throws RESOURCE_EXHAUSTED on the 10,001st (FileWatchRegistry.kt:121-124), even though only directories consume a registration. Any project with node_modules, build/, or .git packs blows past 10k files, so watchFileChanges(recursive = true) on an ordinary project root fails outright rather than watching it. The resource actually being bounded is the WatchKey count, which already has its own limit two lines down — the entry counter should bound work by skipping (SKIP_SIBLINGS / stop registering and log), not by failing the stream.

Same shape in BoundedDirectoryScan: a recursive scan over >10k entries returns nothing at all, and FileSystemDataProviderProxy.scanDirectory maps any failure to null, so the file tree renders empty with no explanation. ScanDirectoryResponse has no truncated field, so today there is no way to say "here are the first N" — worth adding one, since silently-empty is strictly worse than the unbounded behaviour it replaced.

Off-by-one while you are there: the root itself consumes a slot (BoundedDirectoryScan.kt:52 runs before the path == root branch), so the effective ceiling is 9,999 children while the proto comment now promises 10,000.

Fix this →

High - one unreadable subdirectory now fails the whole scan and the whole watch

BoundedDirectoryScan passes a SimpleFileVisitor that does not override visitFileFailed (BoundedDirectoryScan.kt:30-40). Per the SimpleFileVisitor contract that default re-throws, and walkFileTree routes a directory it cannot open to visitFileFailed. So a single AccessDeniedException subdir - a 0700 directory, something root-owned, parts of ~/Library - aborts the scan. The code it replaces (File.walkTopDown() / listFiles()) skipped those silently, and scanDirectory no longer has a try/catch at all, so the escape is an uncaught IOException → UNKNOWN → null in the proxy → empty tree. toRealPath() at line 25 escapes the same way if the directory vanishes after the exists() check.

FileWatchRegistry has the explicit version of the same bug: visitFileFailed rethrows unless disappeared(...), and disappeared answers true only for NoSuchFileException (or a confirmed-absent Windows path), so an AccessDeniedException on any descendant terminates the whole watch (FileWatchRegistry.kt:141-148). The previous catch (_: Exception) per registration was too quiet, but skipping-with-a-log is the right middle, not failing. There is no test for this case on either side, which is why CI is green.

Fix this →

Medium - the native reader changes what readFile can open

The JNA rewrite is well contained and the FIFO test shows why a non-blocking, check-the-handle open was wanted. Three behaviour changes came with it that I do not see called out:

• Symlinked files are now refused. O_NOFOLLOW / FILE_FLAG_OPEN_REPARSE_POINT plus the reparse-point assertion mean a symlinked ~/.zshrc or anything in a dotfiles-style tree fails, with the message Open failed (OS error 62). Note your own scan test asserts the opposite policy for scan (the requested root alias is followed), so read and scan now disagree about symlinks. If refusing is intended, map ELOOP/reparse to a message that says so; if not, resolve and re-validate the target.
• Windows long paths. CreateFileW is called with the plain path (RegularFileReader.kt:118-121), no \\?\ prefix. The JDK's Windows provider adds it; without it files past MAX_PATH stop being readable.
• Non-ASCII paths on POSIX. path.toString() goes through JNA's UTF-8 string encoding, but the JVM decoded that name with sun.jnu.encoding. Where that is not UTF-8 the round trip is lossy and the open fails with ENOENT for names the old File.readBytes() opened. Passing the raw bytes (byte[] from an encoder you control) would remove the question.

Also on the reader: /dev/fd/$descriptor is inspected with a following readAttributes, and on Linux that is a symlink into /proc/self/fd, so the kernel re-resolves the pathname - the KDoc's "never fall back to checking the original path" is true on macOS but weaker on Linux, and it fails outright for an unlinked file. Worth softening the comment or using an fstat-shaped check.

The platform gate (else -> IOException, plus check(Native.POINTER_SIZE == 8)) makes readFile unavailable on any Linux arch outside x86-64/aarch64, where the pure-NIO version worked. Fine if that is the supported set - just say so where the hard-coded O_* constants live, since those are per-ABI.

Medium - limit failures use two different channels

fileSystemLimit() builds a StatusRuntimeException that readFile's broad catch (e: Exception) immediately stringifies into error_message as "RESOURCE_EXHAUSTED: File exceeds one response..." (FileSystemServiceImpl.kt:94-112), so the client has to string-match (and the test at FileSystemLimitsTest.kt:191 does exactly that). That is consistent with this file's own convention, documented in its KDoc around line 208 - but scanDirectory then does the opposite with the same helper and lets the status escape, while still using error_message for "Directory not found". One channel per RPC, please; right now RESOURCE_EXHAUSTED is a status on one method and a string on another.

Related: OVERFLOW now terminates the watch stream (FileWatchRegistry.kt:71) with "rescan and reconnect", but nothing in this repo collects watchFileChanges outside the tests, so there is no reconnecting consumer to honour it. And because flowOn(Dispatchers.IO) applies backpressure while the key stays unreset, a slow collector is itself a way to provoke the overflow that kills the watch. Signalling beats the old silent continue, but the contract needs a client half before it is an improvement in practice.

Low

• confirmDeletion sleeps up to 5 × 10 ms per failing entry, inside the walk (FileWatchRegistry.kt:178-196). A churny tree can stall one add for many seconds; a per-add confirmation budget would bound it.
• keys.removeAll { !it.isValid } runs per visited directory - O(keys) × entries. And the keys.size < 1024 check fires before a *re-*registration of a directory already in the set (Path.register returns the same key), so at exactly 1024 an ENTRY_CREATE for a known directory can fail spuriously.
• Magic numbers that belong in FileSystemLimits: Semaphore(32), keys.size < 1024, the 64 KiB readPage buffer, and the proxy's bare setMaxBytes(1_048_576) (which must equal READ_BYTES for the paging contract to hold, with nothing tying them together).
• checkDepth opens a DirectoryStream for every directory at the boundary depth and errors if it is non-empty - including when everything inside is hidden and includeHidden is false, i.e. when nothing would have been reported anyway.
• validatePath is still a string prefix blocklist, and scan now resolves toRealPath() explicitly - which is a free place to re-check the resolved path (a symlink to /etc is scanned and reported back under the requested prefix). Pre-existing, not introduced here, but this is the security PR and the hook is now sitting right there.
• Worth one line in the PR body: these bounds apply to the out-of-process KERNEL-mode service only. composeApp's in-process FileSystemDataProviderImpl.readFile is unchanged and still unbounded (it has home-directory confinement the gRPC service lacks, and vice versa).
• RpcFailureDiagnostics uses printStackTrace(), which AGENTS.md forbids; the module already has slf4j.
• .github/workflows/filesystem-limits.yml keeps push: branches: ['fix/security-filesystem-limits'] - drop it before merge. (Action pins match the rest of the repo, and choosing :boss-service-filesystem:test + :plugin-platform:plugin-api-ipc:desktopTest gets the jvm("desktop") distinction right.)
• Test coverage gaps, in rough order of what would have caught the above: an unreadable subdirectory in scan and in recursive watch; OVERFLOW; 33 concurrent watches (the current test proves slots are released across sequential collections, never that the 32-slot ceiling reports RESOURCE_EXHAUSTED); a descendant symlink loop in scan.
• sparse files support long offsets... writes at a 2 GiB offset; NTFS files are not sparse by default, so the Windows leg may genuinely allocate/zero ~2 GiB. Not wrong, just worth knowing when that job gets slow.

What is good

• The proxy's paging loop is the strongest part: progress is guaranteed (non-empty page asserted before the write), the 8 MiB ceiling bounds the iteration count, a mid-read size change is caught both per page and at the end, and FileSystemReadPagingTest's emoji-split-across-a-page-boundary case is exactly the test that matters for assembling bytes and decoding once.
• readPage's maximum + 1 probe is a clean way to distinguish "exactly filled the page" from "there is more", and refusing rather than silently truncating a legacy max_bytes = 0 read is the right call for clients that ignore truncated.
• walkFileTree with no options no longer follows descendant symlinks, so the symlink-loop exposure of File.walkTopDown() is gone - and the scan test pins it.
• Reading attributes off the opened object instead of re-checking the pathname, and rewriting entry paths back through the requested (alias) root, are both more careful than what they replace.

I reviewed this statically; I did not run Gradle in this environment (javac/gradle were not permitted), so I am relying on your CI for ktlint/detekt/test results.
· branch fix/security-filesystem-limits

[kshivang]

@Raghav-Bansal-15 - the bounded paging, UTF-8 assembly, and scan/watch cleanup are useful, and the real filesystem tests provide a strong foundation. Review repairs are pushed at 7c43f2db558cbecb2048cc7f5c8c8d8667cf1add: Windows extended-length reads and file-link reads now retain their prior functionality with regressions.

This is a validation/infrastructure handoff, not a claim of an unresolved author defect. Original-head fork run 34595802640 passed; the Windows-path repair head also passed fork run 34736765980. The latest head's required upstream Build & Test 34736950000 and filesystem workflow 34736950063 are approved but queued. Latest-head fork run 34736948170 has now passed on Linux/macOS/Windows; downloaded reports show 31 tests per OS, zero failures/errors, and the workflow includes affected-module ktlint/detekt. Required upstream Build & Test remains queued, so this is not a full merge gate pass. Local tests and root ktlintCheck/detekt could not finish within this bounded pass: the first attempt hit sandbox cache access, then an authorized retry waited behind the shared build lock and was stopped before Gradle execution at final handoff. No current-head full validation pass is claimed.

Claude's suggestions were checked against the intended contract. I retained hard scan/watch ceilings, overflow termination, and persistent I/O failures: silent skipping would falsely advertise complete results or complete watch coverage. Counting the root as visited work is consistent with the work ceiling. The native supported-platform gate is explicit; wider architecture/locale support is not introduced here. The link and long-path regressions were repaired. User-visible partial-result/error presentation can be a separate protocol/provider change; the proxy is currently not constructed in the shipped host topology. #582 is the distinct held-handle path-security layer and remains under author handoff, not a replacement for these resource bounds.

Next steps: finish current-head filesystem/paging tests and required root ktlintCheck/detekt/CI, then refresh dev (it advanced during the review), inspect integration, and mark ready. Include a Windows >260-character file read and an allowed file-link read in the validation. Preserve your original implementation credit and distinguish the review-agent repairs. No merge occurred because the merge policy requires current-head checks to pass. Under the updated final-disposition policy I am converting this open PR to draft while validation is incomplete.

[Raghav-Bansal-15]

Review follow-up: Bound read pages, scan work, and watch registrations, preserve UTF-8 assembly, and close resources on failure/cancellation. Keep allowed link and Windows extended-path reads working. Incomplete scans or watches fail explicitly rather than silently claiming complete coverage.

Validation: 16 filesystem tests plus formatting/static analysis pass locally. The Windows regression now waits for watch readiness and retains a separate 15-second event-delivery deadline after fixture I/O. Latest-head cross-platform CI is pending.

The PR is ready for review and the existing author/reviewer commits are retained. Upstream CI needs maintainer approval. I am following the latest-head checks and have not merged or released anything.

[kshivang]

@Raghav-Bansal-15 - the bounded pages, long offsets, UTF-8 assembly and watch cleanup remain useful. I checked your readiness/deadline revision and downloaded current pre-repair fork reports: 16 filesystem tests plus 3 paging tests pass on each of Linux/macOS/Windows; both focused and full fork workflows are green at c366feab4.

One additional native-platform finding is repaired in review commits 3193f34b6 and c5e5e6f66: Linux ARM64 defines O_NOFOLLOW as 1 << 15 (0x8000), while the reader used the x86 0x20000 bit (O_LARGEFILE on ARM64). A leaf replaced by a link could therefore be followed at the native open boundary on that supported architecture. The repair selects the architecture-correct flag and adds a direct native leaf-link refusal regression, alongside the existing allowed-link RPC test. Source: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/fcntl.h . These two repair commits are agent work, separate from your contribution.

The prior Claude compatibility findings are addressed; hard ceilings and explicit overflow/persistent-I/O failure remain intentional rather than silently claiming complete coverage. #582 is a distinct held-handle layer and already uses the correct ARM64 flag; neither PR replaces the other.

Remaining gate: the repaired head needs filesystem/paging tests and quality checks, including native Linux ARM64 execution of the new regression (the existing hosted matrix does not demonstrate that architecture). I approved the prior head's upstream runs once, but those results cannot validate the new repair. Local Gradle first failed on sandbox cache access. The authorized locked retry then completed: filesystem ktlintCheck/detekt and plugin IPC desktopTest passed, and the new native leaf-link regression passed on macOS. The filesystem suite ran 17 tests with one failure: filtered entries still count toward scan work ceiling received UNAVAILABLE instead of RESOURCE_EXHAUSTED. No diagnostic cause was captured in its XML. Please resolve/re-run this transport-status failure; neither a clean suite pass nor an author-caused transport defect is inferred. Linux ARM64 execution remains unverified. Fresh dev integration must preserve the later kernel/API/capture/trackpad changes. This is a validation handoff after a small repair, not a claim that queued CI is your defect. Converting to draft until those gates are complete.

[Raghav-Bansal-15]

September 15 follow-up: Original and reviewer commits are retained; current dev is integrated.

Preserves maintainer commits 3193f34 and c5e5e6f, including ARM64 O_NOFOLLOW and native leaf-link refusal coverage. The reported UNAVAILABLE versus RESOURCE_EXHAUSTED mismatch did not reproduce in this run.

Validation: 32 filesystem tests (one capability skip), IPC proxy tests, ktlint and detekt pass on Linux ARM64.

Current head 4bfd81db: fresh fork CI is queued/running; no final-head all-green claim. Upstream checks and approval remain separate merge gates. No merge or release performed.

[kshivang]

@claude Please review the current head and September 15 follow-up, particularly the ARM64 read boundary, resource-limit status and current-dev mutation compatibility. Preserve resolved prior findings; this is a bounded follow-up review.

[claude]

Claude finished @kshivang's task in 6m 21s —— View job

---

Bounded follow-up review — head 4bfd81db

• Confirm the merge preserved dev's fix(filesystem): report failed file mutations #680 mutation contract
• Verify the ARM64 O_NOFOLLOW repair (3193f34b6, c5e5e6f66)
• Re-check resource-limit status channels and the UNAVAILABLE report
• Check for new findings introduced by the dev integration
• Post findings

Scoped to the three things asked for. I am not re-litigating the hard-ceiling / explicit-failure policy, the root counting as work, or the supported-platform gate — those were answered by decision and I treat them as resolved. Everything below is either new, or a consequence I can now quantify.

---

ARM64 read boundary — the constant is right; the coverage is one matrix line away

I checked the repair against the kernel headers rather than taking it on trust. arch/arm64/include/uapi/asm/fcntl.h overrides exactly four flags, and O_NOFOLLOW is 0100000 = 0x8000; the asm-generic value is 0400000 = 0x20000. So RegularFileReader.kt:74 is correct, and — the part worth stating explicitly — the other two Linux bits in that expression are not affected, because arm64 overrides only O_DIRECTORY/O_NOFOLLOW/O_DIRECT/O_LARGEFILE. O_NONBLOCK (0x800) and O_CLOEXEC (0x80000) are asm-generic on both arches, so splitting only O_NOFOLLOW is the complete fix, not a partial one. Darwin's 0x0004 | 0x0100 | 0x01000000 is right too, and on macOS/aarch64 the noFollow local is computed and correctly discarded.

Two things follow from that, and the second is the actionable one:

• The arch-conditional is silently dead on the one platform where it is wrong. 0x20000 on arm64 is O_LARGEFILE, which a 64-bit open accepts and ignores — so a regression here does not fail, it just stops refusing links. That is precisely the class of defect that needs a test rather than a run, and the current shape (a local val inside an init block) cannot have one. Extracting internal fun posixOpenFlags(isMac: Boolean, arch: String): Int and pinning all three values would give you host-independent ARM64 coverage of the constant itself — it runs on the x86 runner you already have, and it is the only part of this that a real aarch64 box was needed for. native POSIX open refuses a replaced leaf link still does the behavioural half on whatever arch it runs on.
• Linux ARM64 execution is one line, and the repo already has the runner. filesystem-limits.yml's matrix is ubuntu-latest (x86-64), macos-latest (already aarch64, so the Darwin leg is covered on ARM) and windows-latest. release.yml:921 already runs on ubuntu-24.04-arm, so adding it to this matrix closes the "Linux ARM64 remains unverified" gate directly. I cannot push this myself — the GitHub App is not permitted to modify .github/workflows (FAQ) — so it needs a maintainer commit, together with dropping the push: branches: ['fix/security-filesystem-limits'] trigger that is still on line 5.

One residual on the same file, unchanged since the last round: /dev/fd/$descriptor at :82 is read with a following readAttributes, and on Linux that is a /proc/self/fd symlink, so the kernel re-resolves a pathname. Concretely: a file unlinked or replaced between the open and the attribute read makes the /proc link read "<path> (deleted)" and readAttributes throw, so the open fails where the old File.readBytes() succeeded — an editor doing an atomic-save rewrite while a read is in flight is the realistic trigger. NOFOLLOW_LINKS is not the fix (it would stat the /proc link itself); fstat is, with the honest caveat that glibc only exports it as a symbol from 2.33 and older builds need __fxstat. Worth either taking that on or softening the KDoc's "never fall back to checking the original path", which is true on macOS and not on Linux.

Resource-limit status — the reported mismatch is transport-level, and nothing in the suite can see it

UNAVAILABLE is not a status any handler in this module produces: enforceFileSystemLimit throws StatusRuntimeException(RESOURCE_EXHAUSTED) from inside the visitor, walkFileTree and withContext both propagate it unwrapped, and Status.fromThrowable recovers it. So the failing run was the call not completing at the transport, not the ceiling reporting the wrong code — which matches it not reproducing. Two concrete reasons you currently cannot tell the difference, both fixable:

• RpcFailureDiagnostics only reports UNKNOWN (:23). A transport abort never reaches close(status, …) at all, and any other non-OK status is dropped — which is exactly why "no diagnostic cause was captured in its XML". Widening it to every non-OK status would at least distinguish "handler returned the wrong code" from "the call died", and while you are in the file, printStackTrace() is the thing AGENTS.md names by hand; the module already has slf4j on the compile classpath.
• The ceiling assertion is coupled to a live server and a 10,000-file fixture it does not need. filtered entries still count toward scan work ceiling creates 10,000 real files and asserts an exact wire status code, so every transport hiccup and every runner memory blip presents as this one test failing on a policy assertion. BoundedDirectoryScan is internal in the same module and takes the request plus a CoroutineContext — an in-process test can assert the same invariant with no server and no fixture, if FileSystemLimits becomes an injected value object rather than four const vals. That removes the flake class instead of re-running it, and the RPC-level test can stay as one end-to-end case.

On the two channels: readFile's broad catch (e: Exception) at FileSystemServiceImpl.kt:110 still stringifies its own fileSystemLimit() into error_message, while scanDirectory and watchFileChanges let the identical helper escape as a status. I accept that presentation is separate work, but the one-line half is not presentation: catch (e: StatusRuntimeException) { throw e } ahead of the broad catch would make one helper mean one thing on the wire. The cost is FileSystemLimitsTest:243's contains("explicit byte limits") becoming a code assertion, and the gain is that FileSystemDataProviderProxy's check(response.errorMessage.isBlank()) stops collapsing "too big, page it" and "file not found" into the same IllegalStateException.

Fix this →

Current-dev mutation compatibility — preserved

Diffed the merge result against a448083 for modules/ and the IPC proxy. #680 survives intact: moveReplacing, the typed DirectoryNotEmptyException/AccessDeniedException/IOException mapping in deleteFile, renameFile's ALREADY_EXISTS/NOT_FOUND/PERMISSION_DENIED/INTERNAL ladder and createFile's ALREADY_EXISTS are all byte-identical to dev, and all 307 lines of FileSystemServiceMutationTest come through untouched — including gRPC create with a missing parent retains the deferred UNKNOWN status, which still holds because createFile is not in this PR's blast radius. The only build change is testImplementation(libs.grpc.netty) from dev sitting beside this PR's implementation(libs.jna); the two test classes use different server builders (NettyServerBuilder vs ServerBuilder.forPort) but both resolve to the same provider, so there is no conflict there.

The one contract this PR does change and dev's tests do not cover:

watchFileChanges on a path that does not exist used to complete the stream empty; it now fails. Dev's implementation was if (!Files.exists(root)) { logger.warn(...); return@flow }. The replacement is require(Files.isDirectory(root, NOFOLLOW_LINKS)) at FileWatchRegistry.kt:41, and an IllegalArgumentException is not a Status, so a caller gets a bare UNKNOWN with no description. Failing is defensible — silently completing empty is the "claims coverage it does not have" shape this PR exists to remove — but UNKNOWN is the one code that says nothing, where NOT_FOUND / INVALID_ARGUMENT would say it exactly. There is no test either way, on either side of the merge.

One genuinely new finding

The watch's entry ceiling is per-add(), so cumulative watch work is not actually bounded by SCAN_ENTRIES. var visited = 0 is a local inside Registrations.add (:110), and emitChanges calls add(path, true) afresh for every ENTRY_CREATE directory (:75). So the initial walk is capped at 10,000 entries, and a long-lived watch over a churning tree can then walk unboundedly more, 10,000 at a time. The depth ceiling does not have this problem — it relativizes against root, so it is cumulative by construction — which is what made the difference visible. If the ceiling is meant to bound the watch's total work, visited belongs on Registrations next to keys.

That also makes the pre-existing keys.size < 1024 off-by-one load-bearing rather than cosmetic: it is now the only cumulative bound, and because Path.register returns the same WatchKey for a directory already in the set, at exactly 1024 an ENTRY_CREATE for a known directory raises RESOURCE_EXHAUSTED and kills the watch without needing a new registration at all. The keys.removeAll { !it.isValid } prune on the line above recycles slots, so this is reachable only at the boundary — but it is reachable, and the check should be after the add, or skipped when entry is already registered.

Fix this →

Still open from the last round, unchanged (noted, not re-argued)

Semaphore(32), keys.size < 1024, readPage's 64 KiB buffer and the proxy's bare setMaxBytes(1_048_576) are still outside FileSystemLimits — the last of those must equal READ_BYTES for the paging contract to hold, with nothing tying them together. keys.removeAll { !it.isValid } is still O(keys) per visited directory. confirmDeletion's 5 × 10 ms is still per failing entry inside the walk. checkDepth still errors on a boundary directory whose contents are entirely hidden with includeHidden = false. And BoundedDirectoryScan.scan's toRealPath() at :25 is still not re-validated — which is now asymmetric with readFile, since this PR added exactly that re-check at FileSystemServiceImpl.kt:88-89. A symlink to /etc is scanned and reported back rewritten under the requested prefix, past BLOCKED_PATH_PREFIXES; read refuses it, scan does not. The hook is two lines from where it is already used.

What holds up

The ARM64 flag selection is correct and the reasoning behind it is now verifiable from the headers. The merge is clean: #680's mutation contract is preserved rather than re-resolved, and the reviewed repair commits survived it. The paging half remains the strongest part — guaranteed progress, a bounded iteration count, mid-read size change caught per page and at the end, and the emoji-across-a-page-boundary case pinned. native POSIX open refuses a replaced leaf link is the right shape of regression: it drives the native boundary directly rather than through the RPC, so it cannot be satisfied by the JDK's own resolution.

I reviewed this statically. I did not run Gradle here (no build permitted in this environment), so ktlint/detekt/test results are yours; the only claims above that depend on execution are attributed to your runs, not asserted by me.
· branch fix/security-filesystem-limits

[kshivang]

@Raghav-Bansal-15 - thanks for preserving the ARM64 review repair and rerunning the transport-status fixture. The submitted head has green full/focused fork CI; downloaded focused reports show 59 tests per OS with no failures/errors (Windows one capability skip). Your follow-up is credited separately from earlier review-agent repairs; prior ratings are unchanged.

I merged rebased dev in 40164e6. Filesystem/proxy sources and #680 mutation tests remained byte-identical to your green head; current dev's plugin-registration changes are retained. Review follow-up 5f458b2 adds an actual Linux ARM64 runner to the filesystem matrix and replaces test printStackTrace with SLF4J diagnostics for every non-OK server close. These are review-agent changes. No claim that a server interceptor can observe a transport abort that never reaches close.

Claude reconciliation: retain explicit scan/watch failure rather than silent partial coverage. The visited count bounds each registration walk, not lifetime event processing: a cumulative lifetime counter would eventually terminate a healthy long-lived watch. The live-key cap independently bounds retained registrations. Read errors retain the existing response-field contract; injecting a new limits object and changing error channels are outside this bounded fix. The prior UNAVAILABLE did not reproduce in submitted cross-platform CI; it is not attributed to an author defect. The /proc/self/fd link references the held open file description, not a reopen of its original pathname; the deleted-name display does not itself prove failed stat. No speculative fstat rewrite is warranted here. Missing-watch-root status presentation and duplicate registration at the capacity boundary remain narrow follow-ups, not claims of newly reproduced failures. #582 owns the separate native held-handle/identity watch layer.

Final-head tests/quality and upstream CI remain pending. The required upstream workflows are action_required; automatic approval review refused workflow approval without explicit user authorization. No merge or draft conversion based on this infrastructure gate.

[Raghav-Bansal-15]

Follow-up at 8409e803: Reproduced the scan-root alias bypass and reapply the existing blocked-path policy after resolution, before traversal. The safe regression fails on the old implementation and passes on the fix. Fixture cleanup now uses no-follow traversal and unlinks the external alias in finally. Local filesystem results: 32 passed, one platform skip; quality checks pass.

Original and reviewer commits are preserved. Remaining current-head hosted checks and upstream approval are separate gates; no merge or release.

[kshivang]

@Raghav-Bansal-15 - resumed the assigned review at 8409e8039784df51696f89ba5a15063a73aa1fdc. Verified your resolved-root check runs after toRealPath and before traversal, with no-follow fixture cleanup. The scan-alias fix is your follow-up contribution; prior review-agent changes remain separately attributed. Current-head fork full run 34980549249 and limits run 34980507177 are green. Downloaded reports show 60 tests on each of Linux x86, Linux ARM64, macOS and Windows, zero failures/errors; skips 0/0/1/2 respectively.

The completed Claude review and prior resolution were re-read; no repeated review request or speculative rewrite. Current dev cf21742df has a clean read-only merge-tree with this head. No new source defect identified in this bounded follow-up; prior original-only rating is unchanged.

Upstream current-head workflows still require approval. The user explicitly instructed that the previously rejected workflow-approval action remain blocked without explicit authorization, so I have not retried it or substituted fork CI for the upstream gate. Keeping this PR ready against dev; no merge or draft conversion solely for infrastructure. The recorded manual/native checks remain applicable.

[kshivang]

@Raghav-Bansal-15, your prior exact head passed every reported CI check. Current dev's replaced integration history then caused merge conflicts; these were coordinator integration churn, not a defect in your green contribution.

I pushed a normal merge commit 6123d2db773774e73be9e905b888ca70fc9c5480 preserving current dev's unrelated code and the reviewed filesystem work. Shared-lock :boss-service-filesystem:test :boss-service-filesystem:ktlintCheck :boss-service-filesystem:detekt passes: 33 tests, zero failures/errors, one Linux-only skip on macOS. The diff against integrated dev is confined to filesystem limits, paging, their protocol documentation and tests.

New exact-head CI is running. This stays ready; pending CI is not an author defect. Under the bounded review instruction I will not merge using the old head checks or wait indefinitely. Merge order remains #573 then #581 after refreshing exact head/dev/checks under the shared dev merge lock. Original contribution rating remains 8/10; this integration earns no new contributor credit. Your authorship and @Ayush04-C's earlier #680 mutation contribution remain credited.