@bastani/atomic 0.9.4 → 0.9.5-alpha.10

package/dist/utils/module-require.d.ts

@@ -8,4 +8,15 @@
  * shipped next to the binary.
  */
 export declare function createModuleRequire(moduleUrl: string): NodeJS.Require;
+/**
+ * A resolution base URL safe for the current runtime.
+ *
+ * In compiled binaries (monolithic bun or the Atomic split launcher) the
+ * bundled `import.meta.url` is the build machine's source URL — a foreign-OS
+ * `file://` URL that `fileURLToPath` rejects on other platforms (notably a
+ * macOS `file:///Users/...` URL on Windows). Any API that decodes the base
+ * (`createRequire`, jiti's `createJiti`) then throws `ERR_INVALID_FILE_URL_PATH`.
+ * Anchor to the executable instead, which is always a valid local file URL.
+ */
+export declare function resolutionBaseUrl(moduleUrl: string): string;
 //# sourceMappingURL=module-require.d.ts.map

package/dist/utils/module-require.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"module-require.d.ts","sourceRoot":"","sources":["../../src/utils/module-require.ts"],"names":[],"mappings":"AAIA;;;;;;;;GAQG;AACH,wBAAgB,mBAAmB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,CAAC,OAAO,CAErE","sourcesContent":["import { createRequire } from \"node:module\";\nimport { pathToFileURL } from \"node:url\";\nimport { isBunBinary } from \"../config.ts\";\n\n/**\n * createRequire anchored so bare-specifier resolution works in every runtime.\n *\n * In the compiled binary the bundle is CJS (bytecode), where import.meta.url\n * is rewritten to the original build-machine source path; requiring through it\n * would resolve node_modules against paths that do not exist on user machines.\n * Anchor to the executable instead so resolution walks from the node_modules\n * shipped next to the binary.\n */\nexport function createModuleRequire(moduleUrl: string): NodeJS.Require {\n\treturn createRequire(isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl);\n}\n"]}
+{"version":3,"file":"module-require.d.ts","sourceRoot":"","sources":["../../src/utils/module-require.ts"],"names":[],"mappings":"AAIA;;;;;;;;GAQG;AACH,wBAAgB,mBAAmB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,CAAC,OAAO,CAErE;AAED;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,CAE3D","sourcesContent":["import { createRequire } from \"node:module\";\nimport { pathToFileURL } from \"node:url\";\nimport { isBunBinary } from \"../config.ts\";\n\n/**\n * createRequire anchored so bare-specifier resolution works in every runtime.\n *\n * In the compiled binary the bundle is CJS (bytecode), where import.meta.url\n * is rewritten to the original build-machine source path; requiring through it\n * would resolve node_modules against paths that do not exist on user machines.\n * Anchor to the executable instead so resolution walks from the node_modules\n * shipped next to the binary.\n */\nexport function createModuleRequire(moduleUrl: string): NodeJS.Require {\n\treturn createRequire(resolutionBaseUrl(moduleUrl));\n}\n\n/**\n * A resolution base URL safe for the current runtime.\n *\n * In compiled binaries (monolithic bun or the Atomic split launcher) the\n * bundled `import.meta.url` is the build machine's source URL — a foreign-OS\n * `file://` URL that `fileURLToPath` rejects on other platforms (notably a\n * macOS `file:///Users/...` URL on Windows). Any API that decodes the base\n * (`createRequire`, jiti's `createJiti`) then throws `ERR_INVALID_FILE_URL_PATH`.\n * Anchor to the executable instead, which is always a valid local file URL.\n */\nexport function resolutionBaseUrl(moduleUrl: string): string {\n\treturn isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl;\n}\n"]}

package/dist/utils/module-require.js

@@ -11,6 +11,19 @@ import { isBunBinary } from "../config.js";
  * shipped next to the binary.
  */
 export function createModuleRequire(moduleUrl) {
-    return createRequire(isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl);
+    return createRequire(resolutionBaseUrl(moduleUrl));
+}
+/**
+ * A resolution base URL safe for the current runtime.
+ *
+ * In compiled binaries (monolithic bun or the Atomic split launcher) the
+ * bundled `import.meta.url` is the build machine's source URL — a foreign-OS
+ * `file://` URL that `fileURLToPath` rejects on other platforms (notably a
+ * macOS `file:///Users/...` URL on Windows). Any API that decodes the base
+ * (`createRequire`, jiti's `createJiti`) then throws `ERR_INVALID_FILE_URL_PATH`.
+ * Anchor to the executable instead, which is always a valid local file URL.
+ */
+export function resolutionBaseUrl(moduleUrl) {
+    return isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl;
 }
 //# sourceMappingURL=module-require.js.map

package/dist/utils/module-require.js.map

@@ -1 +1 @@
-{"version":3,"file":"module-require.js","sourceRoot":"","sources":["../../src/utils/module-require.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,WAAW,EAAE,MAAM,cAAc,CAAC;AAE3C;;;;;;;;GAQG;AACH,MAAM,UAAU,mBAAmB,CAAC,SAAiB;IACpD,OAAO,aAAa,CAAC,WAAW,CAAC,CAAC,CAAC,aAAa,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC;AACtF,CAAC","sourcesContent":["import { createRequire } from \"node:module\";\nimport { pathToFileURL } from \"node:url\";\nimport { isBunBinary } from \"../config.ts\";\n\n/**\n * createRequire anchored so bare-specifier resolution works in every runtime.\n *\n * In the compiled binary the bundle is CJS (bytecode), where import.meta.url\n * is rewritten to the original build-machine source path; requiring through it\n * would resolve node_modules against paths that do not exist on user machines.\n * Anchor to the executable instead so resolution walks from the node_modules\n * shipped next to the binary.\n */\nexport function createModuleRequire(moduleUrl: string): NodeJS.Require {\n\treturn createRequire(isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl);\n}\n"]}
+{"version":3,"file":"module-require.js","sourceRoot":"","sources":["../../src/utils/module-require.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,WAAW,EAAE,MAAM,cAAc,CAAC;AAE3C;;;;;;;;GAQG;AACH,MAAM,UAAU,mBAAmB,CAAC,SAAiB;IACpD,OAAO,aAAa,CAAC,iBAAiB,CAAC,SAAS,CAAC,CAAC,CAAC;AACpD,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,iBAAiB,CAAC,SAAiB;IAClD,OAAO,WAAW,CAAC,CAAC,CAAC,aAAa,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,SAAS,CAAC;AACvE,CAAC","sourcesContent":["import { createRequire } from \"node:module\";\nimport { pathToFileURL } from \"node:url\";\nimport { isBunBinary } from \"../config.ts\";\n\n/**\n * createRequire anchored so bare-specifier resolution works in every runtime.\n *\n * In the compiled binary the bundle is CJS (bytecode), where import.meta.url\n * is rewritten to the original build-machine source path; requiring through it\n * would resolve node_modules against paths that do not exist on user machines.\n * Anchor to the executable instead so resolution walks from the node_modules\n * shipped next to the binary.\n */\nexport function createModuleRequire(moduleUrl: string): NodeJS.Require {\n\treturn createRequire(resolutionBaseUrl(moduleUrl));\n}\n\n/**\n * A resolution base URL safe for the current runtime.\n *\n * In compiled binaries (monolithic bun or the Atomic split launcher) the\n * bundled `import.meta.url` is the build machine's source URL — a foreign-OS\n * `file://` URL that `fileURLToPath` rejects on other platforms (notably a\n * macOS `file:///Users/...` URL on Windows). Any API that decodes the base\n * (`createRequire`, jiti's `createJiti`) then throws `ERR_INVALID_FILE_URL_PATH`.\n * Anchor to the executable instead, which is always a valid local file URL.\n */\nexport function resolutionBaseUrl(moduleUrl: string): string {\n\treturn isBunBinary ? pathToFileURL(process.execPath).href : moduleUrl;\n}\n"]}

package/dist/utils/split-launcher.d.ts

@@ -0,0 +1,38 @@
+/**
+ * Split-launcher / foreign-build `import.meta.url` handling.
+ *
+ * Atomic's release binaries use a split launcher: a tiny compiled `atomic` /
+ * `atomic.exe` executable sets `ATOMIC_CODING_AGENT=true` and then dynamically
+ * imports the bundled sidecar `app.js` (plus raw-TS built-in extensions) from
+ * disk next to the executable.
+ *
+ * Unlike pi's single monolithic `bun --compile` binary — where `import.meta.url`
+ * is always a `$bunfs://` virtual-FS URL — the split sidecar bundle carries the
+ * build machine's source path baked in at bundle time (e.g. a macOS
+ * `file:///Users/.../app.js` URL). On Windows, `fileURLToPath()` rejects that
+ * URL with `ERR_INVALID_FILE_URL_PATH` ("File URL path must be an absolute
+ * path") because `/Users/...` has no drive letter, so every site that decodes
+ * `import.meta.url` to a filesystem path must tolerate it.
+ *
+ * These helpers centralize that tolerance: decode normally, and only when the
+ * decode fails under the split launcher fall back to a path resolved relative to
+ * the launcher executable (where the sidecar bundle and its assets actually
+ * live). This mirrors pi's convention of a single detection point rather than
+ * scattered ad-hoc guards.
+ */
+export declare function isSplitLauncherRuntime(): boolean;
+/** Directory containing the launcher executable and its sidecar bundle/assets. */
+export declare function splitLauncherDir(): string;
+/**
+ * Resolve a module's directory from its `import.meta.url`, tolerating the
+ * split-launcher case where the bundled URL is a foreign-OS build path.
+ * `execRelativeSegments` locate the equivalent directory next to the launcher.
+ */
+export declare function moduleDirFromMetaUrl(metaUrl: string, ...execRelativeSegments: string[]): string;
+/**
+ * Resolve a module's filename from its `import.meta.url`, tolerating the
+ * split-launcher case. `execRelativeFile` locates the equivalent file next to
+ * the launcher (used as a stable resolution base, e.g. for `createRequire`).
+ */
+export declare function moduleFileFromMetaUrl(metaUrl: string, execRelativeFile: string): string;
+//# sourceMappingURL=split-launcher.d.ts.map

package/dist/utils/split-launcher.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"split-launcher.d.ts","sourceRoot":"","sources":["../../src/utils/split-launcher.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,sBAAsB,IAAI,OAAO,CAKhD;AAED,kFAAkF;AAClF,wBAAgB,gBAAgB,IAAI,MAAM,CAEzC;AAED;;;;GAIG;AACH,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,oBAAoB,EAAE,MAAM,EAAE,GAAG,MAAM,CAO/F;AAED;;;;GAIG;AACH,wBAAgB,qBAAqB,CAAC,OAAO,EAAE,MAAM,EAAE,gBAAgB,EAAE,MAAM,GAAG,MAAM,CAOvF","sourcesContent":["import { dirname, join } from \"node:path\";\nimport { fileURLToPath } from \"node:url\";\n\n/**\n * Split-launcher / foreign-build `import.meta.url` handling.\n *\n * Atomic's release binaries use a split launcher: a tiny compiled `atomic` /\n * `atomic.exe` executable sets `ATOMIC_CODING_AGENT=true` and then dynamically\n * imports the bundled sidecar `app.js` (plus raw-TS built-in extensions) from\n * disk next to the executable.\n *\n * Unlike pi's single monolithic `bun --compile` binary — where `import.meta.url`\n * is always a `$bunfs://` virtual-FS URL — the split sidecar bundle carries the\n * build machine's source path baked in at bundle time (e.g. a macOS\n * `file:///Users/.../app.js` URL). On Windows, `fileURLToPath()` rejects that\n * URL with `ERR_INVALID_FILE_URL_PATH` (\"File URL path must be an absolute\n * path\") because `/Users/...` has no drive letter, so every site that decodes\n * `import.meta.url` to a filesystem path must tolerate it.\n *\n * These helpers centralize that tolerance: decode normally, and only when the\n * decode fails under the split launcher fall back to a path resolved relative to\n * the launcher executable (where the sidecar bundle and its assets actually\n * live). This mirrors pi's convention of a single detection point rather than\n * scattered ad-hoc guards.\n */\nexport function isSplitLauncherRuntime(): boolean {\n\treturn (\n\t\tprocess.env.ATOMIC_CODING_AGENT === \"true\" &&\n\t\t/(?:^|[\\\\/])atomic(?:\\.exe)?$/i.test(process.execPath)\n\t);\n}\n\n/** Directory containing the launcher executable and its sidecar bundle/assets. */\nexport function splitLauncherDir(): string {\n\treturn dirname(process.execPath);\n}\n\n/**\n * Resolve a module's directory from its `import.meta.url`, tolerating the\n * split-launcher case where the bundled URL is a foreign-OS build path.\n * `execRelativeSegments` locate the equivalent directory next to the launcher.\n */\nexport function moduleDirFromMetaUrl(metaUrl: string, ...execRelativeSegments: string[]): string {\n\ttry {\n\t\treturn dirname(fileURLToPath(metaUrl));\n\t} catch (error) {\n\t\tif (isSplitLauncherRuntime()) return join(splitLauncherDir(), ...execRelativeSegments);\n\t\tthrow error;\n\t}\n}\n\n/**\n * Resolve a module's filename from its `import.meta.url`, tolerating the\n * split-launcher case. `execRelativeFile` locates the equivalent file next to\n * the launcher (used as a stable resolution base, e.g. for `createRequire`).\n */\nexport function moduleFileFromMetaUrl(metaUrl: string, execRelativeFile: string): string {\n\ttry {\n\t\treturn fileURLToPath(metaUrl);\n\t} catch (error) {\n\t\tif (isSplitLauncherRuntime()) return join(splitLauncherDir(), execRelativeFile);\n\t\tthrow error;\n\t}\n}\n"]}

package/dist/utils/split-launcher.js

@@ -0,0 +1,63 @@
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+/**
+ * Split-launcher / foreign-build `import.meta.url` handling.
+ *
+ * Atomic's release binaries use a split launcher: a tiny compiled `atomic` /
+ * `atomic.exe` executable sets `ATOMIC_CODING_AGENT=true` and then dynamically
+ * imports the bundled sidecar `app.js` (plus raw-TS built-in extensions) from
+ * disk next to the executable.
+ *
+ * Unlike pi's single monolithic `bun --compile` binary — where `import.meta.url`
+ * is always a `$bunfs://` virtual-FS URL — the split sidecar bundle carries the
+ * build machine's source path baked in at bundle time (e.g. a macOS
+ * `file:///Users/.../app.js` URL). On Windows, `fileURLToPath()` rejects that
+ * URL with `ERR_INVALID_FILE_URL_PATH` ("File URL path must be an absolute
+ * path") because `/Users/...` has no drive letter, so every site that decodes
+ * `import.meta.url` to a filesystem path must tolerate it.
+ *
+ * These helpers centralize that tolerance: decode normally, and only when the
+ * decode fails under the split launcher fall back to a path resolved relative to
+ * the launcher executable (where the sidecar bundle and its assets actually
+ * live). This mirrors pi's convention of a single detection point rather than
+ * scattered ad-hoc guards.
+ */
+export function isSplitLauncherRuntime() {
+    return (process.env.ATOMIC_CODING_AGENT === "true" &&
+        /(?:^|[\\/])atomic(?:\.exe)?$/i.test(process.execPath));
+}
+/** Directory containing the launcher executable and its sidecar bundle/assets. */
+export function splitLauncherDir() {
+    return dirname(process.execPath);
+}
+/**
+ * Resolve a module's directory from its `import.meta.url`, tolerating the
+ * split-launcher case where the bundled URL is a foreign-OS build path.
+ * `execRelativeSegments` locate the equivalent directory next to the launcher.
+ */
+export function moduleDirFromMetaUrl(metaUrl, ...execRelativeSegments) {
+    try {
+        return dirname(fileURLToPath(metaUrl));
+    }
+    catch (error) {
+        if (isSplitLauncherRuntime())
+            return join(splitLauncherDir(), ...execRelativeSegments);
+        throw error;
+    }
+}
+/**
+ * Resolve a module's filename from its `import.meta.url`, tolerating the
+ * split-launcher case. `execRelativeFile` locates the equivalent file next to
+ * the launcher (used as a stable resolution base, e.g. for `createRequire`).
+ */
+export function moduleFileFromMetaUrl(metaUrl, execRelativeFile) {
+    try {
+        return fileURLToPath(metaUrl);
+    }
+    catch (error) {
+        if (isSplitLauncherRuntime())
+            return join(splitLauncherDir(), execRelativeFile);
+        throw error;
+    }
+}
+//# sourceMappingURL=split-launcher.js.map

package/dist/utils/split-launcher.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"split-launcher.js","sourceRoot":"","sources":["../../src/utils/split-launcher.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAEzC;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,MAAM,UAAU,sBAAsB;IACrC,OAAO,CACN,OAAO,CAAC,GAAG,CAAC,mBAAmB,KAAK,MAAM;QAC1C,+BAA+B,CAAC,IAAI,CAAC,OAAO,CAAC,QAAQ,CAAC,CACtD,CAAC;AACH,CAAC;AAED,kFAAkF;AAClF,MAAM,UAAU,gBAAgB;IAC/B,OAAO,OAAO,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC;AAClC,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,oBAAoB,CAAC,OAAe,EAAE,GAAG,oBAA8B;IACtF,IAAI,CAAC;QACJ,OAAO,OAAO,CAAC,aAAa,CAAC,OAAO,CAAC,CAAC,CAAC;IACxC,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QAChB,IAAI,sBAAsB,EAAE;YAAE,OAAO,IAAI,CAAC,gBAAgB,EAAE,EAAE,GAAG,oBAAoB,CAAC,CAAC;QACvF,MAAM,KAAK,CAAC;IACb,CAAC;AACF,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,qBAAqB,CAAC,OAAe,EAAE,gBAAwB;IAC9E,IAAI,CAAC;QACJ,OAAO,aAAa,CAAC,OAAO,CAAC,CAAC;IAC/B,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QAChB,IAAI,sBAAsB,EAAE;YAAE,OAAO,IAAI,CAAC,gBAAgB,EAAE,EAAE,gBAAgB,CAAC,CAAC;QAChF,MAAM,KAAK,CAAC;IACb,CAAC;AACF,CAAC","sourcesContent":["import { dirname, join } from \"node:path\";\nimport { fileURLToPath } from \"node:url\";\n\n/**\n * Split-launcher / foreign-build `import.meta.url` handling.\n *\n * Atomic's release binaries use a split launcher: a tiny compiled `atomic` /\n * `atomic.exe` executable sets `ATOMIC_CODING_AGENT=true` and then dynamically\n * imports the bundled sidecar `app.js` (plus raw-TS built-in extensions) from\n * disk next to the executable.\n *\n * Unlike pi's single monolithic `bun --compile` binary — where `import.meta.url`\n * is always a `$bunfs://` virtual-FS URL — the split sidecar bundle carries the\n * build machine's source path baked in at bundle time (e.g. a macOS\n * `file:///Users/.../app.js` URL). On Windows, `fileURLToPath()` rejects that\n * URL with `ERR_INVALID_FILE_URL_PATH` (\"File URL path must be an absolute\n * path\") because `/Users/...` has no drive letter, so every site that decodes\n * `import.meta.url` to a filesystem path must tolerate it.\n *\n * These helpers centralize that tolerance: decode normally, and only when the\n * decode fails under the split launcher fall back to a path resolved relative to\n * the launcher executable (where the sidecar bundle and its assets actually\n * live). This mirrors pi's convention of a single detection point rather than\n * scattered ad-hoc guards.\n */\nexport function isSplitLauncherRuntime(): boolean {\n\treturn (\n\t\tprocess.env.ATOMIC_CODING_AGENT === \"true\" &&\n\t\t/(?:^|[\\\\/])atomic(?:\\.exe)?$/i.test(process.execPath)\n\t);\n}\n\n/** Directory containing the launcher executable and its sidecar bundle/assets. */\nexport function splitLauncherDir(): string {\n\treturn dirname(process.execPath);\n}\n\n/**\n * Resolve a module's directory from its `import.meta.url`, tolerating the\n * split-launcher case where the bundled URL is a foreign-OS build path.\n * `execRelativeSegments` locate the equivalent directory next to the launcher.\n */\nexport function moduleDirFromMetaUrl(metaUrl: string, ...execRelativeSegments: string[]): string {\n\ttry {\n\t\treturn dirname(fileURLToPath(metaUrl));\n\t} catch (error) {\n\t\tif (isSplitLauncherRuntime()) return join(splitLauncherDir(), ...execRelativeSegments);\n\t\tthrow error;\n\t}\n}\n\n/**\n * Resolve a module's filename from its `import.meta.url`, tolerating the\n * split-launcher case. `execRelativeFile` locates the equivalent file next to\n * the launcher (used as a stable resolution base, e.g. for `createRequire`).\n */\nexport function moduleFileFromMetaUrl(metaUrl: string, execRelativeFile: string): string {\n\ttry {\n\t\treturn fileURLToPath(metaUrl);\n\t} catch (error) {\n\t\tif (isSplitLauncherRuntime()) return join(splitLauncherDir(), execRelativeFile);\n\t\tthrow error;\n\t}\n}\n"]}

package/docs/changelog.mdx

@@ -3,6 +3,25 @@ title: "Changelog"
 description: "What's new in Atomic"
 ---
 
+<Update label="July 10, 2026">
+
+## Pi 0.80.6 compatibility
+
+- **Synced through upstream Pi 0.80.6.** Atomic and its bundled extensions now use the 0.80.6 Pi runtime packages, including signed empty Anthropic thinking preservation, request-wide GPT-5.4/5.5 long-context pricing, and corrected GPT-5.6 catalog/backend metadata.
+- **Model controls are current.** Atomic accepts `max` wherever the active model advertises it, applies `models.json` overrides to matching extension-registered models and built-ins, and loads legacy `.pi` plus primary `.atomic` layers during normal CLI startup. Disjoint override IDs survive, exact primary entries replace complete legacy entries, and removed catalog IDs fall back instead of being synthesized on resume. See [Models](/models).
+- **Custom pricing tiers are preserved.** Custom `models.json` entries and extension providers can declare complete request-wide `cost.tiers`; matching `modelOverrides` can update scalar rates without losing inherited tiers or replace/clear the tier array explicitly. See [Models](/models#request-wide-cost-tiers) and [Custom Providers](/custom-provider#usage-and-cost).
+- **Safer session and tool behavior.** Invalid explicit bash timeouts fail instead of being clamped; missing exact session IDs warn before creation; lax null or omitted message content is normalized; auth writes surface persistence failures; Windows context traversal terminates at drive roots; and duplicate fork selections are ignored. See [Tools](/tools) and [Usage](/usage).
+- **More reliable streaming and binaries.** Visible custom messages stay before the live assistant row, standalone Linux clipboard reads can fall back to xclip with correctly packaged native bindings, caller-relative `TMPDIR` paths work from external directories, and `--skip-deps` tolerates a missing optional clipboard wrapper.
+
+</Update>
+<Update label="July 9, 2026">
+
+## Dependency refresh
+
+- **Synced with upstream Pi 0.80.5.** Atomic's coding-agent package and bundled extensions now depend on `@earendil-works/pi-ai`, `@earendil-works/pi-agent-core`, and `@earendil-works/pi-tui` through `^0.80.5`.
+- **Refreshed runtime dependencies.** The consolidated dependency update also moves `lru-cache` to `11.5.2`, optional `@dbos-inc/dbos-sdk` to `4.23.6`, and native Cargo dependencies `napi`, `napi-derive`, and `tree-sitter` to their latest stable releases.
+
+</Update>
 <Update label="June 29, 2026">
 
 ## Upstream Pi sync