sliccy 6.155.0 → 6.156.1

package/README.md

@@ -42,10 +42,14 @@ Once you're in, you can:
 
 > Status: active working prototype. The macOS app is the easiest way in today; the extension has been submitted to the Chrome Web Store.
 
+Scoop shells bound supported filesystem traversals and command buffers. See the
+[shell work limits](docs/shell-reference.md#scoop-filesystem-work-limits) for limits
+and command coverage.
+
 ## Why SLICC is different
 
 - **Browser-native, not browser-adjacent.** The agent runtime lives in the browser, and the agent can act on the same browser it lives in. A great mix of power and containment. If you don't like what the AI does, close the browser tab and it's over.
-- **A real shell environment.** Many browser agents are constrained by the tools provided to them. SLICC has an almost-too-real shell with commands like `git`, "`node`", `python`, `playwright`, built-in.
+- **A real shell environment.** Many browser agents are constrained by the tools provided to them. SLICC has an almost-too-real shell with commands like `git`, "`node`", `python`, `playwright`, built-in. Text files use UTF-8 by default; binary pipelines and explicit file encodings preserve their bytes.
 - **UI on the fly.** SLICC can generate rich user interfaces on the fly. These can be small visualizations in a chat response, or full-blown web applications that run in a sidebar, or even a separate tab.
 - **Built around Skills.** Agents don't suffer from missing capabilities, they suffer from skill issues. SLICC can install native skills into `/workspace/skills`, and it also discovers compatible `.agents` / `.claude` skills read-only across the reachable VFS.
 - **More than a coding panel.** Coding is one strong use case, but SLICC is built for practical browser work too: authenticated web apps, repetitive tab work, content operations, debugging, research, and automation.
@@ -280,6 +284,9 @@ SLICC would not have been possible without the pioneering inspiration of [OpenCl
 
 ## Development and deeper docs
 
+Developers can verify native browser storage with `npm run test:opfs` and trial the
+[optional OPFS preload setting](docs/filesystem-preload.md).
+
 If you want to go deeper, the detailed docs live here:
 
 - [Development guide](docs/development.md)

package/dist/node-server/hostfs.d.ts

@@ -57,7 +57,7 @@
  * HTML and the webapp cannot rethrow a faithful `FsError`.
  */
 import type { ErrorRequestHandler, Express, Response } from 'express';
-import { createReadStream } from 'fs';
+import { createReadStream, type Stats } from 'fs';
 import type { HostMountMapping } from './runtime-flags.js';
 /**
  * Cap on a WHOLE-FILE `GET /api/hostfs/read` (and on `PUT /write`). It exists
@@ -174,6 +174,11 @@ export declare function isHostFsStableBodyRequest(req: {
  * passed through untouched.
  */
 export declare const hostFsBodyErrorHandler: ErrorRequestHandler;
+/**
+ * True when `a` and `b` are the same file (device + inode), not merely
+ * similar strings. Path comparison misses the APFS case / NFC-NFD collision.
+ */
+export declare function sameHostFileIdentity(a: Stats, b: Stats): boolean;
 /**
  * Register the /api/hostfs routes for the resolved mount roots. The route
  * surface mirrors `MountBackend` 1:1 (webapp `backend-hostfs.ts`):

package/dist/node-server/hostfs.js

@@ -307,6 +307,7 @@ function statIdentity(s) {
     return {
         ctime: s.ctimeMs,
         ino: Number(s.ino),
+        dev: Number(s.dev),
         uid: s.uid,
         gid: s.gid,
         mode: s.mode,
@@ -515,7 +516,34 @@ async function mkdirOp(target) {
     await mkdir(target, { recursive: true });
     return { ok: true };
 }
+/**
+ * True when `a` and `b` are the same file (device + inode), not merely
+ * similar strings. Path comparison misses the APFS case / NFC-NFD collision.
+ */
+export function sameHostFileIdentity(a, b) {
+    return BigInt(a.dev) === BigInt(b.dev) && BigInt(a.ino) === BigInt(b.ino);
+}
+/**
+ * POSIX `rename(2)`: if both operands name the same directory entry (or
+ * hard links to the same inode), succeed and do nothing.
+ *
+ * Node's `fs.rename` on APFS is not that no-op — a case-only or NFD→NFC
+ * rename rewrites the catalog name. A copy-then-unlink rename is worse:
+ * `open(dest, O_TRUNC)` zeros the only inode, then the subsequent read of
+ * source copies 0 bytes, and `readdir` still shows the original name
+ * (#3107). Compare identity before calling `rename`.
+ */
 async function renameOp(from, to) {
+    try {
+        const fromStat = await lstat(from);
+        const toStat = await lstat(to);
+        if (sameHostFileIdentity(fromStat, toStat))
+            return { ok: true, noop: true };
+    }
+    catch (err) {
+        if (errnoCode(err) !== 'ENOENT')
+            throw err;
+    }
     await rename(from, to);
     return { ok: true };
 }
@@ -644,6 +672,10 @@ export function registerHostFsRoutes(app, roots) {
         }
         await mkdir(dirname(target), { recursive: true });
         const body = Buffer.isBuffer(req.body) ? req.body : Buffer.alloc(0);
+        // The body is fully buffered before this open. `createWriteStream`
+        // would O_TRUNC dest on open, before any byte arrived — the
+        // copy-then-unlink truncation in #3107. writeFile also truncates,
+        // but only with the complete payload already in hand.
         // Write-then-rename would break hardlinks and xattrs on user files;
         // plain writeFile matches what local tools do.
         await writeFile(target, body);