@@ -64,30 +64,56 @@ If your CI pipeline runs typechecking or other static analysis before deploy, ru
 
 ## GitHub Actions
 
-You can deploy from a GitHub repo with a simple GitHub Actions workflow. Running `void init --github` will generate this as `.github/workflows/deploy.yml` in your project:
+You can deploy from a GitHub repo on every push to `main`. Running `void init --github` generates `.github/workflows/void-deploy.yml` in your project.
+
+The workflow authenticates with [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) — there is **no long-lived `VOID_TOKEN` secret to store or rotate**. The job requests a short-lived OIDC token from GitHub, exchanges it at `POST $VOID_API_URL/auth/github-oidc` for a short-lived project-scoped deploy token (about 15 minutes on the free tier; longer on higher plans, capped at ~60 minutes), then runs `void deploy --project <slug>`:
 
 ```yaml
-name: Deploy
+name: Deploy to Void
 on:
   push:
     branches: [main]
 
+# Latest push wins: a newer commit cancels an in-flight deploy for the same
+# repo + branch, so an older commit can never overtake a newer one.
+concurrency:
+  group: void-deploy-${{ github.repository }}-${{ github.ref }}
+  cancel-in-progress: true
+
+permissions:
+  id-token: write
+  contents: read
+
+env:
+  VOID_API_URL: ${{ vars.VOID_API_URL || 'https://api.void.cloud' }}
+  VOID_PROJECT: my-app
+
 jobs:
   deploy:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-      - uses: voidzero-dev/setup-vp@v1
+      - uses: actions/checkout@v6
+      - uses: actions/setup-node@v6
         with:
-          node-version: '22'
-          cache: true
-      - run: vp exec void deploy
-        env:
-          VOID_TOKEN: ${{ secrets.VOID_TOKEN }}
-          VOID_PROJECT: my-app
+          node-version: lts/*
+          cache: npm
+      - run: npm ci
+      - name: Exchange GitHub OIDC token for a Void deploy token
+        run: |
+          OIDC_TOKEN="$(curl -sf \
+            -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
+            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=void" | jq -r '.value')"
+          VOID_TOKEN="$(curl -sf \
+            -H 'Content-Type: application/json' \
+            -d "$(jq -n --arg t "$OIDC_TOKEN" --arg p "$VOID_PROJECT" '{oidcToken: $t, project: $p}')" \
+            "$VOID_API_URL/auth/github-oidc" | jq -r '.token')"
+          echo "::add-mask::$VOID_TOKEN"
+          echo "VOID_TOKEN=$VOID_TOKEN" >> "$GITHUB_ENV"
+      - name: Deploy
+        run: npx void deploy --project "$VOID_PROJECT"
 ```
 
-To get a deploy token, run `void auth token` to copy it to your clipboard, then add it as a GitHub Actions secret.
+Connect the repository to your project once with `void github connect <project> --repo <owner/repo> --executor github_actions` to authorize it. This GitHub Actions path requires the `github_actions` build executor — the default `container` executor will not work with this workflow. The exact steps vary by package manager (the scaffold detects pnpm, yarn, bun, or npm). The `VOID_PROJECT` value is baked in from your linked project when known; otherwise the workflow reads a `VOID_PROJECT` repository variable. To target staging, set a `VOID_API_URL` repository variable to `https://api.staging.void.cloud`.
 
 ## Other Targets
 
 
@@ -56,11 +56,18 @@ Define custom response headers in [`void.json`](../../reference/config) using th
 
 ## Scope
 
-Header rules apply to **all responses** served through the dispatch worker, including static assets, SSR pages, and API routes. They do not apply to:
+Header rules apply to **all responses** served through the dispatch worker, including static assets, SSR pages, API routes, and hashed asset responses (which browsers fetch over `GET` from the immutable edge cache). Serving headers on hashed assets is what lets a cross-origin-isolated app attach `Cross-Origin-Embedder-Policy` and `Cross-Origin-Resource-Policy` to its hashed worker and wasm files — without them, a module worker spawned from a `require-corp` document is blocked.
+
+On hashed (content-addressed, immutable) assets, rules are **additive**. You can add headers such as COOP/COEP/CORP or other security headers, but the platform-managed caching, representation, and framing headers are preserved so an immutable asset cannot be mis-cached or corrupted: `Cache-Control`, `Content-Type`, `Content-Encoding`, `Content-Length`, `Content-Range`, `Accept-Ranges`, and `Transfer-Encoding` keep their platform values even if a broad rule tries to overwrite them. (This is the one case where a user `Cache-Control` does not override the default.)
+
+Header rules do not apply to:
 
-- Hashed asset cache hits (these use immutable caching set by the dispatch worker itself)
 - ISR cache responses (these have their own cache-control headers)
 
+### Blocked headers
+
+Two headers can never be set through rules: `Set-Cookie` and `Clear-Site-Data`. On the shared `*.void.app` domain, `void.app` is the registrable domain, so a cookie operation from one project would reach every project's subdomain. Both are dropped from rule output to keep that tenant boundary intact.
+
 ## Framework `_headers` files
 
 Meta-frameworks like SvelteKit, Nuxt, and Astro generate a `_headers` file with cache rules for their hashed asset directories. Void automatically parses this file during deploy and merges the rules into the deploy manifest.
@@ -74,6 +81,6 @@ No configuration is needed. If the framework generates a `_headers` file, it is
 
 1. `void deploy` reads header rules from the framework `_headers` file (if present) and `routing.headers` in `void.json`, then includes them in the deploy manifest.
 2. The platform stores the rules in the KV routing entry for your project.
-3. The dispatch worker applies matching rules to matching responses before returning them. Cacheable responses are cached with the final headers.
+3. The dispatch worker applies matching rules to matching responses before returning them. Most cacheable responses are cached with the final headers; hashed assets are the exception — their rules are applied on every serve (including cache hits), so a later header-rule change takes effect even when the content hash, and thus the cache entry, is unchanged.
 
 Because rules are evaluated at the edge, there is no extra latency cost. Headers are applied inline before the response is returned and cached.
@@ -86,7 +86,7 @@ After that, the full interactive flow walks through:
 4. **Skills:** links Void skills using the same detected or selected agent context.
 5. **MCP config:** writes MCP server config using that same agent context.
 6. **Demo code:** for existing non-Pages projects, optionally scaffolds a `db/migrations/` directory plus an API route and typed fetch example.
-7. **GitHub Actions:** optionally creates `.github/workflows/deploy.yml` with the right package manager commands.
+7. **GitHub Actions:** optionally creates `.github/workflows/void-deploy.yml`. The workflow deploys on pushes to `main` and authenticates via [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) — no long-lived `VOID_TOKEN` secret is stored in the repo. The job requests an OIDC token (audience `void`), exchanges it at `POST $VOID_API_URL/auth/github-oidc` for a short-lived project-scoped deploy token, then runs `void deploy --project <slug>` with the right package manager. The project slug is baked in from your linked project (`.void/project.json`) when known; otherwise the workflow reads a `VOID_PROJECT` repository variable.
 8. **`env.ts` scaffold:** if the project has no `env.ts` but has `.env` / `.env.example` / `.env.local` / `.env.development*` files on disk, generates an `env.ts` pre-populated with their keys. Values get conservative type inference (`boolean`/`url`/`number`/`string`) — the file carries a banner nudging you to tighten anything the heuristic got wrong.
 9. **Project setup:** optionally logs you in, lets you select or create a project, and writes `.void/project.json` so your first deploy can just be `void deploy`.
 
@@ -98,10 +98,12 @@ Use flags to run individual steps without prompts:
 | ------------ | ------------------------------------------------- |
 | `--tsconfig` | Only update `tsconfig.json`                       |
 | `--agents`   | Set up agent instructions, skills, and MCP config |
-| `--github`   | Only create GitHub Actions workflow               |
+| `--github`   | Only create the GitHub Actions deploy workflow    |
 
 Flags can be combined. When any flag is provided, only the specified steps run and interactive prompts are skipped.
 
+The `--github` workflow uses GitHub OIDC: you connect the repository to your Void project once with `void github connect <project> --repo <owner/repo> --executor github_actions` (see the GitHub section below), and pushes to `main` deploy automatically. There is no `VOID_TOKEN` secret to create or rotate. To target staging, set a `VOID_API_URL` repository variable to `https://api.staging.void.cloud`.
+
 For projects that already have `"extends"`, `void init --tsconfig` preserves the existing config and adds `./.void/tsconfig.json`. If the existing config defines `files` or `compilerOptions.paths`, Void also merges its generated declaration files and aliases into the root config because TypeScript replaces those fields across `extends` instead of deeply merging them.
 
 ### `void prepare`
@@ -564,6 +566,67 @@ PORT=3000
 
 See [Environment Variables](../guide/env-vars.md) for the full guide.
 
+## GitHub
+
+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.
+
+### `void github link`
+
+```
+void github link
+```
+
+Link your current Void account to a GitHub identity. Opens your browser to authorize Void on GitHub (a localhost + PKCE handshake, the same mechanics as `void auth login`), then binds that GitHub identity to the logged-in account. Requires an authenticated CLI (`void auth login` first).
+
+You normally don't need to run this directly — `void github install` runs the link automatically when your account has no GitHub identity yet. Run it on its own to link ahead of time, or to link a GitHub identity without installing the App. If that GitHub account is already linked to a different Void account, the command fails and asks you to use a different GitHub account.
+
+### `void github install`
+
+```
+void github install
+```
+
+Open the GitHub App install page in your browser. If your account has no linked GitHub identity yet, `void github install` first runs the GitHub link automatically (browser authorize), then continues. After installing, run `void github connect` to link a repository to your project.
+
+### `void github installations`
+
+```
+void github installations
+```
+
+List all GitHub App installations linked to your account. Each entry includes the `[id: <installation_id>]` needed for `--installation` in non-interactive use.
+
+### `void github connect`
+
+```
+void github connect [project] [options]
+```
+
+Connect a GitHub repository to a Void project for automatic deploys. On every push to the configured branch, Void builds and deploys your project automatically.
+
+**Options**
+
+| Flag                  | Description                                                                     |
+| --------------------- | ------------------------------------------------------------------------------- |
+| `--project <name>`    | Project name (alias for the positional argument)                                |
+| `--installation <id>` | GitHub App installation ID (required when you have multiple installations)      |
+| `--repo <owner/repo>` | Repository full name — required unless the installation grants exactly one repo |
+| `--branch <name>`     | Branch to deploy from — **required in non-interactive mode**                    |
+| `--executor <type>`   | Build executor: `container` (default) or `github_actions`                       |
+
+**Non-interactive use (CI)**
+
+When stdin is not a TTY, `void github connect` never prompts — it fails closed and names any flag it needs. `--branch` is always required. `--project` must be resolvable (positional / `--project` / `VOID_PROJECT` / linked `.void/project.json`). `--installation` is required only when your account has more than one installation; otherwise the sole installation is used. `--repo` is required when the installation grants access to all repos or to more than one selected repo; when it grants exactly one repo that repo is used automatically. Use `void github installations` to discover the `installation_id`.
+
+```
+void github connect my-app \
+  --installation 42 \
+  --repo owner/my-app \
+  --branch main
+```
+
+**Project resolution** follows the same order as deploy: positional / `--project`, `VOID_PROJECT`, linked project (`.void/project.json`).
+
 ## Custom Domains
 
 ### `void domain add`
 
@@ -31,10 +31,11 @@ async function main() {
   if (!appName) {
     const name = await p.text({
       message: 'Project name:',
+      defaultValue: 'my-app',
       placeholder: 'my-app',
       validate(value) {
-        if (!value?.trim()) {
-          return 'Project name is required';
+        if (value && !value.trim()) {
+          return 'Project name cannot be blank';
         }
       },
     });
 
@@ -38,7 +38,11 @@ export function pmExec(pm: PM): ReadonlyArray<string> {
 export function run(argv: ReadonlyArray<string>, cwd?: string): Promise<void> {
   return new Promise((resolve, reject) => {
     const [cmd, ...args] = argv;
-    const child = spawn(cmd, args, { stdio: 'inherit', cwd });
+    // On Windows the package-manager entry points (npm, npx, pnpm, yarn, bunx)
+    // are .cmd/.ps1 shims that spawn() cannot resolve without a shell, so it
+    // throws ENOENT. Enable a shell only on win32; every arg here is a fixed
+    // literal (no user input reaches argv), so there is no injection surface.
+    const child = spawn(cmd, args, { stdio: 'inherit', cwd, shell: process.platform === 'win32' });
     child.on('close', (code) => {
       if (code === 0) {
         resolve();
 
@@ -8,7 +8,7 @@ import {
 } from '@shikijs/transformers';
 import matter from 'gray-matter';
 import MarkdownExit from 'markdown-exit';
-import type { Token } from 'markdown-exit';
+import type { RuleCore, Token } from 'markdown-exit';
 import anchor from 'markdown-it-anchor';
 import attrs from 'markdown-it-attrs';
 import { full as emoji } from 'markdown-it-emoji';
@@ -82,12 +82,20 @@ async function createCompiler(options?: CompileOptions): Promise<MarkdownExit> {
         lang = 'text';
       }
     }
+    // `markdown-it-attrs` strips the `{1,3-5}` line-highlight ranges out of
+    // `token.info` at parse time (it treats `{…}` as an attribute block), so by
+    // render time only the language remains. The `stash_fence_info` core rule
+    // preserves the original info string on `token.meta.rawInfo` before that
+    // happens; fall back to `token.info` when it is absent (a fence with no
+    // curly meta). Without this, `transformerMetaHighlight` never sees the
+    // ranges and line highlighting silently no-ops.
+    const rawInfo = (token.meta as { rawInfo?: string } | null)?.rawInfo ?? token.info;
     return highlighter.codeToHtml(code, {
       lang,
       themes,
       defaultColor: 'light',
       transformers: shikiTransformers,
-      meta: { __raw: token.info },
+      meta: { __raw: rawInfo },
     });
   };
 
@@ -109,6 +117,20 @@ async function createCompiler(options?: CompileOptions): Promise<MarkdownExit> {
   // GitHub alerts: > [!NOTE], > [!TIP], etc.
   markdown.use(gitHubAlertsPlugin);
 
+  // Preserve the raw fence info string (e.g. `ts {1,3-5}`) on the token before
+  // `markdown-it-attrs` consumes the `{…}` as an attribute block. Anchored
+  // after `block` so fence tokens exist, and before `curly_attributes` (which
+  // runs after `inline`), so the fence renderer can still feed the ranges to
+  // Shiki's `transformerMetaHighlight` via `meta.__raw`.
+  const stashFenceInfo: RuleCore = (state) => {
+    for (const token of state.tokens) {
+      if (token.type === 'fence') {
+        token.meta = { ...token.meta, rawInfo: token.info };
+      }
+    }
+  };
+  markdown.core.ruler.after('block', 'stash_fence_info', stashFenceInfo);
+
   // Attribute syntax: {.class #id}
   markdown.use(attrs);
 
 
@@ -38,6 +38,44 @@ describe('compile', () => {
     expect(result.html).toContain('<span');
   });
 
+  // The 0-based indices of code lines that carry the shiki `highlighted` class.
+  // (Shiki emits one `<span class="line">` per line plus a trailing empty line,
+  // so we compare highlighted positions rather than a fixed line count.)
+  const highlightedLineIndices = (html: string): ReadonlyArray<number> =>
+    [...html.matchAll(/<span class="(line[^"]*)"/g)]
+      .map((match, index) => (match[1].includes('highlighted') ? index : -1))
+      .filter((index) => index >= 0);
+
+  it('highlights a single {N} fence line (markdown-it-attrs must not eat it)', async () => {
+    const result = await compile('```ts {2}\nconst a = 1;\nconst b = 2;\nconst c = 3;\n```');
+    expect(highlightedLineIndices(result.html)).toEqual([1]);
+  });
+
+  it('highlights a {N-M} line range and a combined {a,c-d} set', async () => {
+    const range = await compile('```ts {2-3}\nlet a = 1;\nlet b = 2;\nlet c = 3;\nlet d = 4;\n```');
+    expect(highlightedLineIndices(range.html)).toEqual([1, 2]);
+
+    const combined = await compile(
+      '```ts {1,3-4}\nlet a = 1;\nlet b = 2;\nlet c = 3;\nlet d = 4;\n```',
+    );
+    expect(highlightedLineIndices(combined.html)).toEqual([0, 2, 3]);
+  });
+
+  it('highlights {N} even for languages without comment syntax (e.g. text)', async () => {
+    const result = await compile('```text {1}\nalpha\nbeta\n```');
+    expect(highlightedLineIndices(result.html)).toEqual([0]);
+  });
+
+  it('leaves fences without curly meta unhighlighted', async () => {
+    const result = await compile('```ts\nconst a = 1;\nconst b = 2;\n```');
+    expect(result.html).not.toContain('highlighted');
+  });
+
+  it('still applies markdown-it-attrs to non-fence content', async () => {
+    const result = await compile('Hello {.greeting}\n');
+    expect(result.html).toContain('greeting');
+  });
+
   it('converts emoji shortcodes', async () => {
     const result = await compile('Hello :tada:');
     expect(result.html).toContain('\u{1F389}'); // 🎉