void 0.26.0 → 0.26.1

package/{skills/void/docs → docs}/guide/sandboxes.md

@@ -97,7 +97,7 @@ Files, running processes, and listening servers last only as long as the contain
 
 ## Configuration
 
-The default environment provides Node.js 24 on Debian Trixie. Managed platform deploys use Cloudflare's managed Node.js image.
+The default environment provides Node.js 26 on Debian Trixie. Managed platform deploys use Cloudflare's managed Node.js image.
 
 Use `void.config.ts` when you need a custom image or container size:
 
@@ -118,7 +118,7 @@ See the [configuration reference](../reference/config.md#sandbox) for binding na
 Custom images must include the helper matching Void's installed Sandbox SDK version. The SDK image supplies this binary, but is not a runnable environment itself:
 
 ```dockerfile
-FROM node:24.21.0-trixie-slim
+FROM node:26.10.0-trixie-slim
 COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
 WORKDIR /workspace
 CMD ["sleep", "infinity"]

package/{skills/void/docs → docs}/guide/sse.md

@@ -168,6 +168,4 @@ export const GET = defineHandler(async (c) => {
 });
 ```
 
-Native `EventSource` can send cookies with `withCredentials: true`. For non-cookie auth, generate a short-lived signed URL and validate it in the route handler.
-
 For shared topics and subscriptions, use [Live Event Streams](./live.md). For two-way communication, use [WebSockets](./websockets.md).

package/{skills/void/docs → docs}/guide/storage.md

@@ -42,12 +42,12 @@ const head = await storage.head('uploads/photo.jpg');
 A common pattern is serving uploaded files from an API route:
 
 ```ts
+// routes/files/[key].ts
 import { defineHandler } from 'void';
 import { storage } from 'void/storage';
 
 export const GET = defineHandler(async (c) => {
-  const key = c.req.param('key');
-  const object = await storage.get(key);
+  const object = await storage.get(`uploads/${c.req.param('key')}`);
 
   if (!object) {
     return c.notFound();
@@ -56,11 +56,16 @@ export const GET = defineHandler(async (c) => {
   const headers = new Headers();
   object.writeHttpMetadata(headers);
   headers.set('etag', object.httpEtag);
+  // Don't let an uploaded HTML or SVG file run as a page on your site.
+  headers.set('X-Content-Type-Options', 'nosniff');
+  headers.set('Content-Disposition', 'attachment');
 
   return new Response(object.body, { headers });
 });
 ```
 
+Files your users upload can contain HTML or scripts. Store them under keys your server picks, and serve them with `nosniff` and `Content-Disposition: attachment`. `<img>` and `<video>` tags still display them; opening the URL directly downloads the file.
+
 ## Custom bindings
 
 Use `createStorage(bucket)` with your own R2 binding, or in tests:

package/{skills/void/docs → docs}/guide/websockets.md

@@ -151,6 +151,10 @@ Messages are JSON events. Raw string and binary messages are not supported.
 
 When Void auth is enabled, every WebSocket hook receives the current user as `ctx.user`, or `null` for an anonymous connection. Use `onBeforeConnect` to reject unauthenticated clients.
 
+Connections from another origin are anonymous unless that origin is in your auth `trustedOrigins`. If you read your own cookies from `ctx.request`, check its `Origin` header yourself.
+
+`ctx.user` is resolved when the socket connects and stays the same for that connection, even if the user later signs out or the session is revoked. For actions that must respect a ban or role change, re-check your own records in `onMessage` and close the connection with `ctx.connection.close()` in rooms or `ctx.socket.close()` in `defineWebSocket()`.
+
 ## Hooks
 
 Both `defineRoom()` and `defineWebSocket()` support:

package/docs/integrations/agents.md

@@ -0,0 +1,37 @@
+---
+outline: deep
+---
+
+# Using Void with Coding Agents
+
+`void init` sets up coding agents as part of project initialization:
+
+```sh
+npx void init
+```
+
+New projects get a minimal `AGENTS.md` explaining Void and where to read its docs.
+In an existing project, Void asks before creating, appending to, or updating
+`AGENTS.md`. It preserves your instructions outside the Void section. Declining
+keeps the file unchanged; CI and non-interactive runs skip changes to existing
+projects' instructions.
+
+The complete Markdown docs ship at `node_modules/void/docs/`. Start with
+`guide/quickstart.md` for setup and `reference/cli.md` for commands. Agents can
+read them directly, even without a linked skill.
+
+## Skills
+
+Skills point your agent to the commands and docs it needs for the task. They link to the installed `void` package, so the guidance matches the version your app uses.
+
+Void ships two skills:
+
+- **`void`:** commands and docs for app development.
+- **`migrate-vite-cloudflare-to-void`:** migration skill for converting existing `@cloudflare/vite-plugin` apps to Void.
+
+Skills are linked automatically by `void init` when it detects a supported
+agent's configuration. For example, Claude Code uses `.claude/skills/` and Codex
+uses `.agents/skills/`. The skills use the app's installed docs so their guidance
+matches its Void version. Globally installed skills can use the docs in their
+Void package when there is no local installation. If no agent is detected, the
+instructions still point directly to the bundled docs.

package/{skills/void/docs → docs}/integrations/frameworks/astro.md

@@ -10,7 +10,7 @@ Use Void with [Astro](https://astro.build/) for resource detection, typed databa
 
 - [Astro 6+](https://astro.build/blog/astro-6/) is required to use `import { x } from "void/x"` helpers in Astro apps.
 - You also need to enable `"nodejs_als"` under `compatibility_flags` in your Cloudflare config.
-  :::
+:::
 
 ## Setup
 
@@ -30,8 +30,8 @@ npm install -D @astrojs/cloudflare void
 ### 3. Configure `astro.config.mjs`
 
 ```js
-import { defineConfig } from 'astro/config';
 import cloudflare from '@astrojs/cloudflare';
+import { defineConfig } from 'astro/config';
 import { voidPlugin } from 'void';
 
 export default defineConfig({
@@ -85,9 +85,9 @@ export const prerender = false;
 Use `void/db` in API routes and server-side code:
 
 ```ts
+import { users } from '@schema';
 import type { APIRoute } from 'astro';
 import { db } from 'void/db';
-import { users } from '@schema';
 
 export const GET: APIRoute = async () => {
   const rows = await db.select().from(users);

package/{skills/void/docs → docs}/integrations/frameworks/nuxt.md

@@ -33,10 +33,14 @@ export default defineNuxtConfig({
   nitro: {
     preset: 'cloudflare-module',
     cloudflareDev: { configPath: './.void-wrangler.jsonc' },
+    // Required for Nuxt 4.6.0 on Windows.
+    externals: {
+      inline: [/[\\/]node_modules[\\/]nuxt[\\/]dist[\\/]/],
+    },
     alias: {
       // Nitro has its own bundler that doesn't use Vite aliases.
       // Duplicate @schema here so Nitro can resolve it.
-      '@schema': resolve(__dirname, 'db/schema.ts'),
+      '@schema': resolve(import.meta.dirname, 'db/schema.ts'),
     },
   },
   vite: { plugins: [voidPlugin()] },
@@ -75,9 +79,9 @@ Void-managed auth is not supported in framework mode yet. Use Better Auth's offi
 ### Database
 
 ```ts
+import { users } from '@schema';
 // server/api/users.get.ts
 import { db } from 'void/db';
-import { users } from '@schema';
 
 export default defineEventHandler(async () => {
   return db.select().from(users);

package/{skills/void/docs → docs}/integrations/hono.md

@@ -17,25 +17,33 @@ Once `hono` is installed in your app, you can use built-in middleware, helpers,
 Use Hono's built-in middleware in your global middleware files or per-route:
 
 ```ts
+import { cors } from 'hono/cors';
 // middleware/01.cors.ts
 import { defineMiddleware } from 'void';
-import { cors } from 'hono/cors';
 
 export default defineMiddleware(cors({ origin: 'https://example.com' }));
 ```
 
 ```ts
-// middleware/02.cache.ts
-import { defineMiddleware } from 'void';
 import { cache } from 'hono/cache';
+// routes/api/products.ts (per-route cache)
+import { defineHandler } from 'void';
+import { listProducts } from '../../lib/products';
 
-export default defineMiddleware(cache({ cacheName: 'my-app', cacheControl: 'max-age=3600' }));
+export const GET = defineHandler(
+  cache({ cacheName: 'products', cacheControl: 'max-age=3600' }),
+  async () => ({ products: await listProducts() }),
+);
 ```
 
+::: warning
+`cache()` stores one response per URL and returns it to every visitor. It skips requests with an `Authorization` header, but not cookies. Use it only on routes whose response is the same for everyone, never on a route that reads the signed-in user. To cache pages, use [revalidation](../guide/edge/revalidation.md), which skips requests that carry a cookie.
+:::
+
 ```ts
+import { bearerAuth } from 'hono/bearer-auth';
 // routes/api/webhooks/stripe.ts (per-route usage)
 import { defineHandler } from 'void';
-import { bearerAuth } from 'hono/bearer-auth';
 
 export const POST = defineHandler(bearerAuth({ token: 'webhook-secret' }), async (c) => {
   const body = await c.req.json();
@@ -48,9 +56,9 @@ export const POST = defineHandler(bearerAuth({ token: 'webhook-secret' }), async
 Hono's context helpers are available on `c` in every handler:
 
 ```ts
+import { stream } from 'hono/streaming';
 // routes/api/download.ts
 import { defineHandler } from 'void';
-import { stream } from 'hono/streaming';
 
 export const GET = defineHandler((c) => {
   return stream(c, async (stream) => {
@@ -76,9 +84,9 @@ export const GET = defineHandler((c) => {
 Any `hono/*` or `@hono/*` package works. Install the package in your app, then use it directly:
 
 ```ts
+import { rateLimiter } from 'hono-rate-limiter';
 // middleware/01.rate-limit.ts
 import { defineMiddleware } from 'void';
-import { rateLimiter } from 'hono-rate-limiter';
 
 export default defineMiddleware(rateLimiter({ windowMs: 60_000, limit: 100 }));
 ```

package/{skills/void/docs → docs}/integrations/nodejs-bun-deno.md

@@ -111,6 +111,7 @@ The following imports are **not available** with a non-CF target and produce a c
 | `void/storage` | R2 (blob storage)        |
 | `void/auth`    | Void-managed Better Auth |
 | `void/ai`      | Workers AI               |
+| `void/sandbox` | Cloudflare Sandboxes     |
 | `void/env`     | Typed environment schema |
 
 If you need a database or storage, use an external provider and connect via standard Node.js libraries.

package/{skills/void/docs → docs}/reference/api/auth.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Authentication {#auth}
 
-Imported from `"void"` or `"void/auth"`. Client-side helpers imported from `"void/client"`.
+Imported from `"void/auth"`. Client-side helpers imported from `"void/client"`.
 
 ## `defineAuth(config)` {#defineauth-config}
 

package/{skills/void/docs → docs}/reference/api/handlers.md

@@ -41,8 +41,8 @@ Creates a handler with input validation using any [Standard Schema](https://gith
 Validated input is passed as the second argument to the handler.
 
 ```ts
-import { defineHandler } from 'void';
 import * as v from 'valibot';
+import { defineHandler } from 'void';
 
 export const POST = defineHandler.withValidator({
   body: v.object({
@@ -103,6 +103,8 @@ Void’s reserved `/__void` endpoints use their own authentication and are exclu
 
 When credentials come from `void/env`, wrap the reads in functions so they are resolved per request after Void has bound the runtime env.
 
+If `password` resolves to an empty value, requests fail with a server error instead of passing the gate.
+
 For app-specific bypasses such as health checks or public webhooks, compose that logic in your own middleware before calling `basicAuth()`.
 
 ```ts
@@ -182,7 +184,7 @@ export default defineQueue<{ to: string; subject: string }>(async (batch, env) =
 ```ts
 function defineQueue<T>(
   handler: (batch: QueueBatch<T>, env: CloudEnv['Bindings']) => void | Promise<void>,
-): QueueFn;
+): TypedQueueHandler<T>;
 ```
 
 ## `defineRender(handler)` {#definerender-handler}

package/{skills/void/docs → docs}/reference/api/pages.md

@@ -32,6 +32,10 @@ function voidVue(options?: VoidVueOptions): Plugin[];
 interface VoidVueOptions {
   vue?: VuePluginOptions; // passed through to @vitejs/plugin-vue
   viewTransitions?: boolean; // enable View Transitions API for navigations
+  prefetch?: {
+    hoverDelay?: number;
+    cacheFor?: number | string | [string, string];
+  };
 }
 ```
 

package/{skills/void/docs → docs}/reference/cli/auth.md

@@ -32,11 +32,6 @@ platform. In a non-interactive shell, pass `--platform cloudflare|void` or use
 the explicit `void cloudflare` and `void account` commands. Choosing a destination
 for authentication does not change the project's deploy target.
 
-`void auth whoami`, `void auth link`, and `void auth token` remain supported for
-existing scripts. `whoami` follows the selected destination; `link` and `token`
-are Void account operations. Prefer `void auth status`, `void account link`, and
-`void account token` in new scripts.
-
 ## Void platform account {#void-platform-account}
 
 ### `void account login` {#void-account-login}

package/{skills/void/docs → docs}/reference/cli/database.md

@@ -24,7 +24,7 @@ Show migration status. Displays which migrations are applied or pending locally,
 
 ## `void db reset` {#void-db-reset}
 
-Drop the local D1 database and re-apply all migrations. Does not affect the remote database.
+Drop the development database and re-apply all migrations. D1 resets the local database; PostgreSQL and MySQL drop all tables in the `DATABASE_URL` database from `.env`. Does not affect the deployed database.
 
 ## `void db seed` {#void-db-seed}
 
@@ -79,11 +79,10 @@ Open [Drizzle Studio](https://orm.drizzle.team/docs/drizzle-kit-studio) for the
 
 By default, targets the local database. Pass `--remote` to open Studio against the deployed database:
 
-- **PostgreSQL and MySQL projects**: fetch the stored connection string from the platform and open Studio against it. If the URL isn't stored yet, run `void db set-url` first.
+- **Hosted PostgreSQL and MySQL projects**: fetch the stored connection string from the platform and open Studio against it. If the URL isn't stored yet, run `void db set-url` first.
+- **Direct Cloudflare PostgreSQL and MySQL projects**: use `DATABASE_URL` from the current shell.
 - **D1 projects**: remote Studio is not yet supported. Use `void db execute --remote` for ad-hoc queries against your deployed D1 database.
 
-On direct Cloudflare PostgreSQL/MySQL targets, remote Studio uses `DATABASE_URL` from the current shell. Direct D1 Studio remains unsupported; use `void db execute --remote`.
-
 ## `void db rename-migrations` {#void-db-rename-migrations}
 
 Rename existing migrations from the old numeric prefix format (`0001_name.sql`) to timestamp-based format (`20260410161500_name.sql`). Updates local tracking table and remote records if logged in with a linked project.

package/{skills/void/docs → docs}/reference/cli/generate.md

@@ -109,7 +109,7 @@ void gen cron hourly-sync
 void gen queue <name>
 ```
 
-Create a queue consumer file in `queues/` with `defineQueue`, a `Message` interface, and commented-out batch options.
+Create a queue consumer file in `queues/` with `defineQueue`, a `Message` type, and commented-out batch options.
 
 ```sh
 void gen queue emails

package/{skills/void/docs → docs}/reference/cli/github.md

@@ -6,6 +6,8 @@ outline: deep
 
 Deploy-on-GitHub works from **any** Void login — Google, GitHub, or other SSO. The first time you connect GitHub, Void links your GitHub identity to your current account (a one-time step, independent of how you logged in); it never creates a second account.
 
+Project-scoped `github` and `build` commands resolve the project in the same order as deploy: the `[project]` argument or `--project`, then `VOID_PROJECT`, then the linked project (`.void/project.json`).
+
 ## `void github link` {#void-github-link}
 
 ```
@@ -78,8 +80,6 @@ void github connect my-app \
   --branch main
 ```
 
-**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
-
 You can connect only repositories your GitHub account can access.
 
 A project has one GitHub connection. Running `void github connect` on a project that is already connected fails. To connect a different repository, run `void github disconnect` first.
@@ -107,8 +107,6 @@ The CLI prompts for new settings using the current values as defaults. In CI, pa
 void github update my-app --executor github_actions
 ```
 
-**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
-
 ## `void github status` {#void-github-status}
 
 ```
@@ -127,15 +125,13 @@ Show the connected repository, branch, executor, and workflow. Container builds
 void github status my-app
 ```
 
-**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
-
 ## `void github disconnect` {#void-github-disconnect}
 
 ```
 void github disconnect [project]
 ```
 
-Disconnect a project from its GitHub repository, stopping automatic deploys. Any in-flight builds for the project are cancelled (their deploy tokens are revoked) before the connection is removed. If the project has no connection, it reports that and exits successfully. To point a project at a different repository, disconnect first, then run `void github connect`.
+Disconnect a project from its GitHub repository, stopping automatic deploys. Any in-flight builds for the project are cancelled before the connection is removed. If the project has no connection, it reports that and exits successfully. To point a project at a different repository, disconnect first, then run `void github connect`.
 
 You are asked to confirm before anything is removed. Pass `--yes` to skip the prompt; `--yes` is **required** in a non-interactive shell (CI), where there is no prompt to answer.
 
@@ -150,8 +146,6 @@ You are asked to confirm before anything is removed. Pass `--yes` to skip the pr
 void github disconnect my-app --yes
 ```
 
-**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
-
 ## Build {#build}
 
 Inspect Deploy-on-GitHub builds.
@@ -171,9 +165,6 @@ Stream, tail, or download the build logs for a **container** build. With no
 | `--output <file>`, `-o`  | Write logs to a file instead of stdout (appends while following).         | stdout  |
 | `--project <slug>`, `-p` | Target project.                                                           | linked  |
 
-**Project resolution** follows the same order as deploy: positional / `--project`,
-`VOID_PROJECT`, linked project (`.void/project.json`).
-
 Builds run on **GitHub Actions** keep their logs on GitHub — the command prints
 the Actions run URL instead of streaming. Only the last 10,000 log lines of a
 container build are retained.

package/{skills/void/docs → docs}/reference/cli/platform-config.md

@@ -89,4 +89,4 @@ when using `--yes`. Recovery requires Cloudflare management/database authority,
 original recovery keys, and a successful browser provider test. Use
 `--client-secret-env <name>` for new or rotated credentials.
 
-For automation, supply `VOID_OPERATOR_TOKEN` with an explicit `VOID_API_URL` or `--connection`. Operator tokens are stored separately from application deployment credentials. The API checks your current administrator access on every request. See [Using Scripts](../../guide/platform/administration/operations.md#using-scripts) for an example.
+For automation, see [operator authentication](./platform.md#operator-authentication).

package/{skills/void/docs → docs}/reference/cli/platform-email.md

@@ -42,9 +42,8 @@ has ended and the operation is at least 24 hours old, inspect the exact resource
 named by the preview and attest whether its write was `applied` or `not-applied`.
 Applied writes continue at the next step; not-applied writes retry the same
 persisted intent. The running platform version must match that intent, so restore
-the matching version before recovering an operation created by older code. The
-preview pins the step, attempt, connection and route generations, resource
-identity, and digest used by the apply request. Time alone never retries a write.
+the matching version before recovering an operation created by older code. Time
+alone never retries a write.
 
 `shared-recipients` discovers shared inbound addresses, provider rule names and
 IDs, and interrupted creation intents, including projects awaiting deletion.

package/{skills/void/docs → docs}/reference/cli/platform-installation.md

@@ -113,7 +113,7 @@ use `repair --dashboard-url <origin>` or `upgrade --dashboard-url <origin>`.
 Preview with `--plan` first. Existing Access protection must cover the configured
 dashboard origin before maintenance can proceed. See [Optional Dashboard](../../guide/platform/installation/domains.md#optional-dashboard).
 
-After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. An upgrade that preserves every deployed Worker also preserves its secrets. For an email-enabled installation without its encrypted recovery file, restore `VOID_PLATFORM_EMAIL_SIGNING_SECRET`; recreating only the email gateway needs that key and does not need the Cloudflare runtime token or JWT signing key. Recreating the API or proxy also requires the email key when email is enabled, in addition to their normal secrets. Recreating the API requires its original runtime-token, GitHub, R2, JWT, and project-encryption values; recreating the proxy requires the runtime token and JWT signing key.
+After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. See [Manage an installation from another machine](../../guide/platform/installation/maintenance.md#manage-an-installation-from-another-machine) for the secrets needed to recreate a missing Worker.
 
 | Command     | Behavior                                                                                                    |
 | ----------- | ----------------------------------------------------------------------------------------------------------- |

package/{skills/void/docs → docs}/reference/cli/platform-operations.md

@@ -54,6 +54,7 @@ void platform system asset-migrations [--page <n>] [--limit <n>]
 void platform system events [--page <n>] [--limit <n>]
 void platform system backfill-queue-tokens
 void platform system sandbox-drain [--cursor <opaque-cursor>]
+void platform system rotate-proxy-tokens [--project <id> | --all]
 ```
 
 `overview` shows platform totals and recent activity. `health` checks the configured services and database, and exits with a nonzero status if a check fails. `cli-versions` reports the CLI versions used by deployments.
@@ -64,6 +65,8 @@ void platform system sandbox-drain [--cursor <opaque-cursor>]
 
 `sandbox-drain` removes legacy tenant-owned Sandbox resources. Use `--plan` to preview and `--yes` to apply, then pass `nextCursor` as `--cursor` to continue. Application traffic stays paused during cleanup.
 
+`rotate-proxy-tokens` gives projects new platform credentials on their live Worker and the Workers kept for rollback, without a redeploy. Workers kept for rollback whose author can no longer deploy keep the old credentials. Use `--project <id>` for one project or `--all` for every project, with `--plan` to preview and `--yes` to apply. `--plan` alone shows every rotation that is still running. Each run does a bounded batch and the platform finishes the rest in the background; a rotation takes about 6 minutes per project, longer while a deploy is running. Use `--plan` to check progress until nothing is pending or failed. Running `--yes` again with `--project` or `--all` while a rotation is still running starts one more rotation for that project. When a rotation is finished, the previous credentials no longer work. Each rotation starts a new version of the project's live Worker, so WebSocket connections reconnect once.
+
 Use the [platform lifecycle commands](./platform-installation.md#lifecycle-commands) to maintain your installation's Workers.
 
 ## Hosted Workers {#operator-workers}

package/{skills/void/docs → docs}/reference/cli/platform-users.md

@@ -16,13 +16,13 @@ void platform user show <id>
 Use the same ID to change a plan, suspend or restore the account, or delete it:
 
 ```sh
-void platform user plan <id> <free|solo|pro|sponsored|custom>
+void platform user plan <id> <plan-id>
 void platform user suspend <id> [--reason <text>]
 void platform user restore <id>
 void platform user delete <id>
 ```
 
-Suspending a user blocks their applications. Deleting a user also deletes their project resources. A plan change updates resource limits while preserving any administrator suspension.
+Suspending a user blocks their applications, including scheduled jobs and queue consumers. While the account is suspended, each queue message is retried about once an hour, and each retry uses one of its queue's retries. Messages that run out of retries are dropped: after about 3 hours with the default of 3 retries, and at once for a queue with `maxRetries: 0`. Restore an account suspended by mistake promptly; queue delivery resumes within about an hour. Deleting a user also deletes their project resources. A plan change updates resource limits while preserving any administrator suspension.
 
 The last active administrator cannot be deleted or suspended. Both previews and
 actual mutations enforce this rule, including in the browser admin UI. Allowed

package/{skills/void/docs → docs}/reference/cli/project.md

@@ -10,6 +10,7 @@ Show deployments for the configured target.
 
 - Void targets show recent hosted deployments; `[name]` looks up a project by slug and otherwise the linked project is used.
 - Cloudflare targets list Worker Versions, identify the active version, and show the recorded migration count. A project name is not accepted because the Worker name comes from `cloudflare.name` in `void.config.ts`.
+- Owners and admins also see a warning when the platform cannot finish [replacing the project's credentials](../../guide/project-collaboration.md#change-or-remove-access).
 
 ## `void project link [name]` {#void-project-link-name}
 
@@ -36,7 +37,7 @@ void project team accept <invitation-id>
 void project team decline <invitation-id>
 ```
 
-Project-scoped commands use `--project`, then `VOID_PROJECT`, then the linked project. Invitations can target only an email address already registered to a user on that platform; they do not create accounts or grant signup access. Only the invited account can accept or decline its invitation.
+Project-scoped commands use `--project`, then `VOID_PROJECT`, then the linked project. Invitations can target only an email address already registered to a user on that platform; they do not create accounts or grant signup access. Only the invited account can accept or decline its invitation. `list` shows the same credential warning as `void project status`.
 
 Readers can view the project but cannot deploy. Collaborators can deploy and manage deploy prerequisites. Project administrators can additionally manage domains, email destinations, GitHub configuration, and the project team. The owner alone can delete the project. See [Project Collaboration](../../guide/project-collaboration.md) for the full role boundaries.
 
@@ -137,7 +138,7 @@ void project logs --level error --range 12h
 void project logs --level error --filter websocket
 ```
 
-Logs include top-level `console.*` calls and uncaught errors captured by Cloudflare Tail. If you catch an error and save it only to your database, it won't appear here. Also log it with `console.error()` or `logger.error()` from `void/log`.
+Logs include top-level `console.*` calls and uncaught errors captured by Cloudflare Tail. If you catch an error and save it only to your database, it won't appear here. Also log it with `console.error()` or `logger.error()` from `void/log`. On hosted Void targets, pass the `Error` object itself to `console.error()`, as in `console.error('Save failed:', error)`, to see its stack trace under the log line. Logging only `error.message` shows no stack.
 
 For errors that never reach your Worker, such as edge routing errors or static site requests, use `void project requests --status 5xx`.
 
@@ -195,7 +196,7 @@ This command is hosted-only. Direct Cloudflare deploys are local operations and
 
 ## `void project delete [name]` {#void-project-delete-name}
 
-Permanently delete a hosted Void project and all its resources (databases, KV namespaces, R2 buckets, deployments). Requires typing the project slug to confirm.
+Permanently delete a hosted Void project and all its resources (databases, KV namespaces, R2 buckets, deployments). Requires typing the project slug to confirm; `--force` (`-f`) skips the prompt.
 
 If `[name]` is omitted, uses the linked project.
 
@@ -211,4 +212,4 @@ Purge all cached pages for the linked project. The edge cache will clear within
 
 If `--project` is provided, purges that project's cache instead of the linked project.
 
-This command is currently hosted-only. Direct Cloudflare cache purge fails closed with guidance.
+This command is hosted-only. For direct Cloudflare targets, redeploy or purge the configured ISR KV namespace yourself.

package/{skills/void/docs → docs}/reference/cli/secrets.md

@@ -14,8 +14,6 @@ List production secret names for the saved target. Secret values are never print
 
 ## `void secret put` {#void-secret-put}
 
-On hosted projects, secret writes and deletes return a retryable conflict while a deployment or rollback is in progress. Wait for that operation to finish and retry; the rejected operation leaves the stored secret unchanged.
-
 ```
 void secret put <name> [--project <name>]
 void secret put <name=value> [--project <name>]
@@ -27,7 +25,7 @@ Value input modes:
 - prompt (TTY): `void secret put API_KEY` (masked input)
 - stdin: `echo -n "abcd" | void secret put API_KEY`
 
-On a direct Cloudflare target, the value is sent to Cloudflare over stdin and stored as an encrypted Worker secret.
+On a direct Cloudflare target, the value is stored as an encrypted Worker secret.
 
 ## `void secret sync` {#void-secret-sync}
 
@@ -51,6 +49,8 @@ void secret delete <name> [--project <name>]
 
 Secret commands use the platform saved in `.void/project.json`. Hosted project resolution follows the same order as deploy (`--project`, env var, linked project). Direct Cloudflare targets reject `--project` and use the pinned root Cloudflare config.
 
+On hosted projects, secret writes and deletes return a retryable conflict while a deployment or rollback is in progress. Wait for that operation to finish and retry; the rejected operation leaves the stored secret unchanged.
+
 ## Env Schema {#env-schema}
 
 ### `void env check` {#void-env-check}

package/{skills/void/docs → docs}/reference/cli/setup.md

@@ -28,7 +28,7 @@ Resources recorded in `void.lock.json` without a matching definition appear sepa
 ## `void init` {#void-init}
 
 ```sh
-void init [--tsconfig] [--github] [--agents] [--git | --no-git]
+void init [--tsconfig] [--github] [--git | --no-git]
 ```
 
 Set up a new or existing Void project. In an empty directory, choose Vite+ or Vite, a framework, and a D1, PostgreSQL, MySQL, or Static Pages starter.
@@ -37,6 +37,12 @@ In an existing app, Void adds missing dependencies and scripts and updates the V
 
 The wizard also sets up TypeScript, agent instructions, environment declarations, and a deployment target. Choose Cloudflare, a Void platform, or skip deployment setup. If you skip sign-in, run `void connect` when you're ready. See [Quick Start](../../guide/quickstart.md).
 
+Every init run sets up coding agents. New projects get a minimal `AGENTS.md`
+pointing to `node_modules/void/docs/`. Existing projects prompt before the file
+is created, appended to, or updated; CI and non-interactive runs leave existing
+projects' instructions unchanged. Skills are linked for detected agents. See
+[Coding Agents](../../integrations/agents.md).
+
 Outside an existing repository or workspace package, Void offers to initialize Git. Use `--git` to initialize without a prompt or `--no-git` to skip it. CI requires `--git` to initialize. Workspace packages do not accept these flags.
 
 Run selected setup steps with:
@@ -44,10 +50,10 @@ Run selected setup steps with:
 | Flag         | Purpose                                                        |
 | ------------ | -------------------------------------------------------------- |
 | `--tsconfig` | Update TypeScript configuration, preserving existing settings. |
-| `--agents`   | Set up agent instructions and skills for detected agents.      |
 | `--github`   | Create the GitHub Actions deployment workflow.                 |
 
-These flags can be combined and skip the other wizard steps. Add `--git` if you also want Git initialization.
+These flags can be combined and skip the other wizard steps. Coding agent setup
+still runs. Add `--git` if you also want Git initialization.
 
 For Cloudflare workflows, add a `CLOUDFLARE_API_TOKEN` repository secret. PostgreSQL and MySQL apps also need `DATABASE_URL`.
 
@@ -60,11 +66,3 @@ void prepare
 ```
 
 Generates Void’s types and TypeScript configuration without starting the dev server or building the app. Run it after a fresh clone or before typechecking in CI.
-
-## Agent {#agent}
-
-### `void init --agents` {#void-init-agents}
-
-Adds Void instructions to `AGENTS.md` and links skills for detected coding agents. Existing instructions outside the Void block are preserved.
-
-If no supported agent is detected, `AGENTS.md` links to the bundled docs. See [Coding Agents](../../integrations/agents.md).

package/{skills/void/docs → docs}/reference/cli.md

@@ -73,7 +73,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void email allow <address>`      | Add a recipient and send a verification email                                 |
 | `void email disallow <address>`   | Remove a recipient from the allowlist                                         |
 | `void email domain`               | Send and receive at your own domain on a Cloudflare zone                      |
-| `void init`                       | Setup wizard for new or existing projects                                     |
+| `void init`                       | Set up a new or existing project, including coding agents                     |
 | `void migrate`                    | Convert legacy `void.json` and root Wrangler JSON/JSONC into `void.config.ts` |
 
 ## Binary Invocation {#binary-invocation}