Integrate dev: process isolation, filesystem safety, recovery and faster CI

[kshivang]

Integrate the reviewed development batch into main after manual testing.

Changes include workspace state consistency (#564), terminal session cleanup (#570), process log limits (#574), authenticated IPC (#575), bounded repair and mastery execution (#568, #569), auth browser lifecycle cleanup (#704), bounded filesystem reads/watches and RPC authorization (#573, #581), and CI workflow optimization (#748).

Individual PR validation is recorded in their reviews. Integration CI and manual debug-build testing remain to be completed; this PR does not claim those checks have passed. No deployment has been performed as part of this integration request.

[supabase]

This pull request has been ignored for the connected project pcnwqamqdnsadranufjv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[kshivang]

@claude review this

[claude]

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

---

Review: PR #776 — integrate dev (process isolation, filesystem safety, recovery, CI)

• Gather context (diff, commits, AGENTS.md, rollout docs)
• Review IPC auth + process isolation
• Review filesystem bounds/authorization
• Review terminal / mastery / repair changes
• Review CI workflow + build config changes
• Post review

Scope note: this is a code read of git diff origin/main...HEAD (100 files, +8815/−1119). I did not run Gradle (needs the GitHub Packages token and a long multi-platform build) — consistent with the PR body, which says integration CI and manual testing are still outstanding.

Overall this is high-quality, unusually well-documented defensive work. The authorization-at-emission pattern (IpcCall.current() re-read inside every collect, not just at admission), revocation that cancels already-admitted calls and their coroutines, temp-file + ATOMIC_MOVE workspace persistence, and the paging test that splits a UTF-8 emoji across pages are all the right shape. Findings below are mostly consequences and asymmetries rather than defects in the new code itself.

---

1. A restarted process is permanently locked out of its own state keys

StateServiceImpl.update stamps ownerInstance = caller.instanceId, and ProcessTokenRegistry.issue mints a fresh UUID per credential — so a replacement incarnation of the same processId is a different owner. Read isolation here is deliberate and pinned (IpcAuthorizationTest.kt:175), but the write side is not covered and has no recovery path:

• stateStore is a ConcurrentHashMap with no eviction, no TTL, and no deleteState RPC (StateServiceImpl.kt:32, only referenced within that file).
• Nothing in KernelBootstrap clears state when a process exits or is revoked.
• setState requires existing.ownerInstance == currentCaller.instanceId || authority == HOST.

So after any crash + RestartPolicy.ON_FAILURE restart — or a REPAIR_STRATEGY_RESTART from the orchestrator, which is the default for an unknown failure — the replacement gets PERMISSION_DENIED on every key its predecessor wrote, for the remaining life of the kernel. Suggest dropping (or orphaning to ownerInstance = null… careful, that means shared) the entries belonging to a revoked instance in revoke/revokeIfCurrent, or allowing takeover on write when the recorded owner instance is no longer in the registry and processId matches. Fix this →

2. connectToService throws for known services, returns null for unknown

ChildProcessBootstrap.kt:195:

if (serviceName !in serviceAddresses) return null
error("Direct peer IPC requires a host-authorized channel; …")

The failure shapes are inverted relative to caller expectations: a consumer written against BossIpcClient? handles "service absent" gracefully and takes an IllegalStateException in exactly the case that used to work. There are no in-repo callers (the consumer is boss-microkernel-runtime, paired per docs/authenticated-ipc-rollout.md), so this lands as a runtime crash in the other repo rather than a compile error. Consider either removing/renaming the method so the paired repo fails to compile, or returning null with a warn for both cases.

3. Filesystem write paths are not symlink-hardened, while the read path now is

readFile resolves and re-validates (FileSystemServiceImpl.kt:93-94):

val resolved = file.toPath().toRealPath()
validatePath(resolved.toString())

writeFile (:129), createFile (:160), deleteFile (:181) and renameFile (:258) validate only the caller-supplied string, so a symlink sitting at an allowed path and pointing at /etc/... is still followed. Every RPC is now IpcCall.requireHost()-gated, so this is not plugin-reachable and the severity is low — but it undercuts the stated purpose of BLOCKED_PATH_PREFIXES and the asymmetry will read as intentional to the next person. (Separately: BLOCKED_PATH_PREFIXES is POSIX-only, so the deny-list is a no-op on Windows.)

4. Path-validation failures escape as bare UNKNOWN

In readFile, writeFile and scanDirectory, validatePath(request.path) sits outside the try, so its IllegalArgumentException leaves the handler unmapped — gRPC turns it into UNKNOWN with no description. The identical failure detected after toRealPath() (inside the try) comes back as a populated errorMessage. renameFile's own KDoc already explains why this matters ("gRPC deliberately does not leak exception messages"). Mapping to INVALID_ARGUMENT would make the two agree.

5. Revocation check on the streaming hot path takes a process-wide lock

ProcessIdentityInterceptor.sendMessage (:57) calls registry.principalFor(token) for every outbound message, and principalFor is @Synchronized on the whole ProcessTokenRegistry (ProcessTokenRegistry.kt:45). That serializes terminal output chunks, file-watch events and event-bus fan-out for every process through one monitor, alongside issue/revoke. Since the interceptor already holds an onRevoked subscription for this exact credential, it could hold the IssuedCredential and read its AtomicBoolean instead, or the maps could be ConcurrentHashMaps.

6. Terminal pump uses a fixed 10 ms poll where the log drain backs off adaptively

TerminalSession.startPump (:39-47) busy-polls input.available() with Thread.sleep(10) on a dedicated thread per session (up to 16). ProcessLogDrain, added in the same batch, does 1 ms → 100 ms adaptive backoff — and AGENTS.md documents that choice explicitly. The terminal path pays up to 10 ms of added latency on every echo while never dropping below 100 Hz wakeups when idle. Worth sharing the drain's backoff.

7. New workflows: dead push triggers, no post-merge signal, duplicated work

authenticated-ipc.yml, filesystem-limits.yml and native-file-boundaries.yml all carry push: branches: ['fix/security-…'] — the per-feature branches these PRs came from, which stop existing once this merges. None of them triggers on push to main/dev, so after this merge they only ever run on future PRs touching those paths; there is no signal on main. Also worth weighing against the CI-perf commit in the same batch: they add 3 OS × 4 modules of tests that build.yml's merged ./gradlew test build already runs, plus a GraalVM nativeCompile per OS. (I can't edit .github/workflows/** — GitHub App permissions — so this is a flag, not a patch.)

8. Smaller notes

• re2j bypasses the version catalog convention. gradle/libs.versions.toml:51 declares the version, but modules/boss-orchestrator/build.gradle.kts:40 consumes it as implementation("com.google.re2j:re2j:${libs.versions.re2j.get()}") rather than a [libraries] alias, unlike bouncycastle-pkix added in the same commit.
• SpawnIpcSecurity.create:39 builds a throwaway ProcessTokenRegistry() solely to mint a random host token, discarding the registry's map inserts. A named SecureRandom hex helper would say what it means; issue() also allocates a fresh SecureRandom per call.
• MasteryServiceImpl.updateStatus touches execStatus and runningJobs without taking stateLock itself — correct today because all three call sites hold it, but nothing states that precondition, and the eviction loop reads runningJobs.
• TerminalServiceImpl.createSession holds the global lock across ProcessBuilder.start(), so every other terminal RPC (listSessions, sendInput's lookup, close) queues behind process creation. The comment justifies the ordering; the cost isn't mentioned.
• OrchestratorServiceImpl's repairHistory.keys.first { it !in pendingRepairs } is only total because of require(historyLimit >= pendingLimit) in init. That's the right guard — a one-line comment at the first would stop someone relaxing the require.
• validateLaunchInput in TerminalSession throws bare require failures which createSession maps to INVALID_ARGUMENT — good — but the generic message ("Invalid terminal command or environment") also swallows a genuine IllegalArgumentException from anywhere else in the launch path.

What I checked and found correct

Slot/permit accounting in TerminalServiceImpl.createSession's delivered/admitted/pumping finally-ladder (every path releases exactly once, including the session == null IOException path); ProcessLogStreams lease/refcount lock ordering (Lease → writers, never the reverse); TerminalOutputBuffer's replay window and updates.first { it != revision } wakeup (no lost-update window); the orchestrator's claim-then-release approval path; BoundedDirectoryScan's emptySet() (don't-follow-links) walk plus post-toRealPath re-validation; FileSystemDataProviderProxy's accumulate-then-decode paging; BossIpcServer/BossIpcClient call sites all updated to the new required-credential signatures.

---

• branch dev

[kshivang]

Addressed the confirmed correctness findings from Claude's review:

• A replacement process can now overwrite its own previous-incarnation state with an unconditional update. Previous private values remain unreadable; stale optimistic-version writes, foreign-process writes, and revoked callers are rejected. The authenticated transport regression test covers each case.
• connectToService now returns null with a warning for unavailable direct peer channels instead of throwing for a known service. It never opens an unauthenticated channel.
• Filesystem path policy checks canonical existing ancestors, including missing destinations beneath symlinked directories. Rename/delete act on the final entry without following its link; recursive deletion no longer traverses directory symlinks. System-root checks include canonical POSIX aliases and Windows SystemRoot. This remains a host-only best-effort guard, not a race-proof filesystem sandbox.
• Invalid and traversal paths return descriptive INVALID_ARGUMENT statuses. Regression tests cover the policy, read/write/scan over authenticated RPC, and refused rename preservation.
• Authenticated IPC and filesystem-limit workflows now run on main/develop/dev pushes with their existing path filters. Native-file workflow already had these integration triggers and needed no change.

The proposed registry-lock and polling changes are performance suggestions rather than demonstrated correctness failures. They are intentionally left unchanged to preserve revocation guarantees and avoid an unmeasured concurrency rewrite. The smaller style suggestions are not merge blockers.

Validation: 103 test cases, 0 failures/errors, 1 skipped; both modules pass ktlint and detekt; actionlint and git diff --check pass. Some unchanged task results were reused. This does not claim fresh hosted CI or that the already-running debug JVM contains these new changes.