wood-fired-tasks 2.0.1 → 2.0.3

package/CHANGELOG.md

@@ -13,6 +13,47 @@ vulnerabilities, supply-chain pinning) are always called out under `Security`.
 
 _No changes yet._
 
+## [v2.0.3] - 2026-06-08
+
+### Fixed
+- **`tasks setup` device-flow login no longer fails with `invalid_client` on
+  servers backed by a real IdP.** The RFC 8628 device-flow `client_id` was
+  validated against `OIDC_CLIENT_ID` — the *IdP's* OAuth client id used for the
+  browser SSO leg — while the CLI sends a logical `'wft-cli'`. On any server
+  using e.g. Google, those never matched, so `POST /auth/device/code` returned
+  `400 invalid_client` and setup crashed. The device-flow client id is now a
+  **separate** setting, `OIDC_DEVICE_CLIENT_ID` (defaults to `'wft-cli'` on both
+  server and CLI), decoupled from `OIDC_CLIENT_ID` and not part of the
+  all-or-nothing OIDC group — so the stock CLI authenticates against a stock
+  server with no configuration. Operators who customize it set the same value
+  on both sides.
+- **Remote onboarding degrades gracefully when the device flow can't start.**
+  A failed/throwing `POST /auth/device/code` (e.g. `invalid_client`, or a
+  network error) previously aborted `tasks setup` with a raw stack-trace-style
+  error. It now logs the reason and falls back to manual personal-access-token
+  entry, so onboarding can still complete.
+
+### Changed
+- New optional env var **`OIDC_DEVICE_CLIENT_ID`** (default `'wft-cli'`),
+  documented in `docs/SETUP.md`. No action required for existing deployments
+  using the default CLI.
+
+## [v2.0.2] - 2026-06-08
+
+### Fixed
+- **`tasks setup` remote onboarding now reaches the automated device-flow login
+  instead of always falling back to manual PAT entry.** The onboarding probe
+  read the server's OIDC state from `GET /health/detailed`, but v2.0's identity
+  cutover put that endpoint behind Bearer-PAT auth — so an unauthenticated probe
+  (the only kind possible *before* you have a token) always got `401`, the OIDC
+  state was "undeterminable", and setup fell back to asking you to paste a
+  personal access token. The probe now targets the **public** `GET /auth/login`
+  endpoint (`redirect: 'manual'`): a `3xx` redirect to the IdP means browser
+  login is available (`ready`), a `501` means OIDC is disabled (`manual-pat`).
+  Verified against a live OIDC-ready server: the probe now resolves `ready`
+  where it previously 401'd, so the device-flow browser login launches as
+  intended.
+
 ## [v2.0.1] - 2026-06-08
 
 ### Fixed

package/dist/api/server.js

@@ -362,6 +362,11 @@ export async function createServer(options) {
                 }, 'device-flow origin resolved to localhost — CLI verification_uri will be unroutable for remote clients');
             }
             const clientId = config.OIDC_CLIENT_ID;
+            // #833: the device-flow `client_id` is a SEPARATE logical identifier the
+            // CLI sends (default `'wft-cli'`), NOT the IdP's OAuth client id. Using
+            // OIDC_CLIENT_ID here rejected the stock CLI with `invalid_client` on any
+            // real-IdP server. Always defaulted, so device flow works out of the box.
+            const deviceClientId = config.OIDC_DEVICE_CLIENT_ID;
             await server.register(authRoutes, {
                 prefix: '/auth',
                 oidcConfig: app.oidcConfig,
@@ -413,9 +418,9 @@ export async function createServer(options) {
                 await scope.register(authPlugin);
                 await scope.register(deviceCodeRoute, {
                     origin,
-                    expectedClientId: clientId,
+                    expectedClientId: deviceClientId,
                 });
-                await scope.register(deviceTokenRoute, { expectedClientId: clientId });
+                await scope.register(deviceTokenRoute, { expectedClientId: deviceClientId });
                 await scope.register(deviceHtmlRoute, { origin });
             });
         }

package/dist/cli/commands/setup.d.ts

@@ -274,9 +274,11 @@ export declare function writeRemoteMcpEntryOnly(options?: RunSetupOptions): RunS
  */
 export type SetupMode = 'local' | 'service' | 'remote';
 /**
- * Coarse OIDC subsystem state reported by `GET /health/detailed` (task #357).
- * Mirrors the server's `oidc.state` enum so the remote-setup branch selector
- * (#807) can route deterministically.
+ * Coarse OIDC subsystem state used by the remote-setup branch selector (#807)
+ * to route deterministically. Derived by {@link probeOidcState} from the public
+ * `/auth/login` endpoint (`ready` = redirects to IdP, `disabled` = 501 stub).
+ * `degraded` is retained for back-compat but is no longer emitted by the probe
+ * (an unhealthy OIDC surfaces as an inconclusive status → manual-PAT fallback).
  */
 export type OidcState = 'ready' | 'disabled' | 'degraded';
 /**
@@ -287,10 +289,12 @@ export type OidcState = 'ready' | 'disabled' | 'degraded';
  */
 export type RemoteOnboardingMethod = 'device-flow' | 'manual-pat';
 /**
- * Result of probing `GET /health/detailed` for the OIDC state.
- *  - `{ ok: true, oidc }` — the probe returned 2xx and an `oidc.state`.
- *  - `{ ok: false, reason }` — network error / non-2xx / unparseable body.
- *    The `reason` is surfaced to the user before falling back to manual PAT.
+ * Result of probing the server for whether browser/device-flow login is
+ * available.
+ *  - `{ ok: true, oidc }` — the probe got a conclusive answer (`ready` =
+ *    device-flow available, `disabled` = no OIDC → manual PAT).
+ *  - `{ ok: false, reason }` — network error / inconclusive status. The
+ *    `reason` is surfaced to the user before falling back to manual PAT.
  */
 export type OidcProbeResult = {
     ok: true;
@@ -302,13 +306,22 @@ export type OidcProbeResult = {
 /** Injectable probe signature so tests can drive each branch without a server. */
 export type OidcProbe = (baseUrl: string) => Promise<OidcProbeResult>;
 /**
- * Default OIDC probe: `GET <baseUrl>/health/detailed` and read `oidc.state`.
+ * Default OIDC probe: `GET <baseUrl>/auth/login` (the browser-login entry
+ * point) and read OIDC availability from the HTTP status.
  *
- * `/health/detailed` is auth-protected on the server (Bearer PAT), but the only
- * field we need — `oidc.state` — is returned in the JSON body regardless of the
- * auth-derived status code as long as the route renders. We treat ANY non-2xx
- * or unparseable/missing `oidc.state` as a probe failure and fall back to the
- * manual-PAT escape hatch (the route may not even exist on an older server).
+ * Why NOT `/health/detailed` (the original #807 target): v2.0's identity
+ * cutover put `/health/detailed` behind Bearer-PAT auth, so an unauthenticated
+ * probe — which is the ONLY kind possible during onboarding, before any PAT
+ * exists — gets a hard `401 {"error":"UNAUTHORIZED"}` with NO `oidc.state` in
+ * the body. That made this probe always fail and `setup --remote` always fall
+ * back to manual-PAT entry, defeating the automated device-flow login
+ * (wood-fired-tasks #831).
+ *
+ * `/auth/login` is PUBLIC (`skipAuth: true`) and an unambiguous signal:
+ *   - OIDC ready    → `302` redirect to the IdP authorize URL.
+ *   - OIDC disabled → the disabled-stub returns `501`.
+ * We do NOT follow the redirect (`redirect: 'manual'`) — only its status
+ * matters. Any other/unreachable status is inconclusive → manual-PAT fallback.
  * Bounded by a 5s timeout so a half-open server can't hang `setup --remote`.
  */
 export declare function probeOidcState(baseUrl: string): Promise<OidcProbeResult>;
@@ -367,8 +380,8 @@ export declare function persistManualPat(baseUrl: string, token: string): Promis
 export interface RunSetupInteractiveOptions extends RunSetupOptions {
     /**
      * Injectable OIDC-state probe for the `--remote` path (#807). Defaults to
-     * {@link probeOidcState} (a real `GET /health/detailed`). Tests stub this to
-     * drive the ready / disabled / degraded / probe-failure branches.
+     * {@link probeOidcState} (a real `GET /auth/login`, public). Tests stub this
+     * to drive the ready / disabled / probe-failure branches.
      */
     oidcProbe?: OidcProbe;
     /**

package/dist/cli/commands/setup.js

@@ -546,40 +546,50 @@ export function writeRemoteMcpEntryOnly(options = {}) {
     };
 }
 /**
- * Default OIDC probe: `GET <baseUrl>/health/detailed` and read `oidc.state`.
+ * Default OIDC probe: `GET <baseUrl>/auth/login` (the browser-login entry
+ * point) and read OIDC availability from the HTTP status.
  *
- * `/health/detailed` is auth-protected on the server (Bearer PAT), but the only
- * field we need — `oidc.state` — is returned in the JSON body regardless of the
- * auth-derived status code as long as the route renders. We treat ANY non-2xx
- * or unparseable/missing `oidc.state` as a probe failure and fall back to the
- * manual-PAT escape hatch (the route may not even exist on an older server).
+ * Why NOT `/health/detailed` (the original #807 target): v2.0's identity
+ * cutover put `/health/detailed` behind Bearer-PAT auth, so an unauthenticated
+ * probe — which is the ONLY kind possible during onboarding, before any PAT
+ * exists — gets a hard `401 {"error":"UNAUTHORIZED"}` with NO `oidc.state` in
+ * the body. That made this probe always fail and `setup --remote` always fall
+ * back to manual-PAT entry, defeating the automated device-flow login
+ * (wood-fired-tasks #831).
+ *
+ * `/auth/login` is PUBLIC (`skipAuth: true`) and an unambiguous signal:
+ *   - OIDC ready    → `302` redirect to the IdP authorize URL.
+ *   - OIDC disabled → the disabled-stub returns `501`.
+ * We do NOT follow the redirect (`redirect: 'manual'`) — only its status
+ * matters. Any other/unreachable status is inconclusive → manual-PAT fallback.
  * Bounded by a 5s timeout so a half-open server can't hang `setup --remote`.
  */
 export async function probeOidcState(baseUrl) {
-    const probeUrl = new URL('/health/detailed', baseUrl).toString();
+    const probeUrl = new URL('/auth/login', baseUrl).toString();
     let response;
     try {
-        response = await fetch(probeUrl, { method: 'GET', signal: AbortSignal.timeout(5000) });
+        response = await fetch(probeUrl, {
+            method: 'GET',
+            redirect: 'manual',
+            signal: AbortSignal.timeout(5000),
+        });
     }
     catch (err) {
         const message = err instanceof Error ? err.message : String(err);
         return { ok: false, reason: `could not reach ${probeUrl}: ${message}` };
     }
-    if (!response.ok) {
-        return { ok: false, reason: `${probeUrl} returned HTTP ${response.status}` };
+    // 3xx → /auth/login is redirecting to the IdP → device-flow is available.
+    // (`redirect: 'manual'` surfaces the real 3xx status rather than following
+    // it; some runtimes report an opaque-redirect as status 0 with type
+    // 'opaqueredirect', which we also treat as a redirect.)
+    if ((response.status >= 300 && response.status < 400) || response.type === 'opaqueredirect') {
+        return { ok: true, oidc: 'ready' };
     }
-    let body;
-    try {
-        body = await response.json();
-    }
-    catch {
-        return { ok: false, reason: `${probeUrl} returned a non-JSON body` };
+    // 501 → the OIDC-disabled stub → no browser login; use a manual PAT.
+    if (response.status === 501) {
+        return { ok: true, oidc: 'disabled' };
     }
-    const oidc = body?.oidc?.state;
-    if (oidc === 'ready' || oidc === 'disabled' || oidc === 'degraded') {
-        return { ok: true, oidc };
-    }
-    return { ok: false, reason: `${probeUrl} did not report an oidc.state` };
+    return { ok: false, reason: `${probeUrl} returned HTTP ${response.status}` };
 }
 /**
  * Map a probe outcome to the onboarding method (task #807).
@@ -799,32 +809,53 @@ export async function runRemoteOnboarding(options = {}) {
         log('This server supports browser login (OIDC ready); using the device flow.');
     }
     // 3. Branch on the selected method.
-    const method = selectRemoteOnboardingMethod(probeResult);
+    let method = selectRemoteOnboardingMethod(probeResult);
     const oidc = probeResult.ok ? probeResult.oidc : null;
     if (method === 'device-flow') {
         // Self-provision a PAT via the OIDC device flow (#806). runDeviceLogin owns
         // the entire RFC 8628 exchange AND persists the minted PAT via the
         // credentials writer (writeCredentials) — there is NO host token-mint path
-        // here. On failure it has already emitted its own error output; we just
-        // propagate ok:false without writing anything.
-        const result = await deviceLogin({
-            baseUrl,
-            clientId: process.env['OIDC_CLIENT_ID'] ?? 'wft-cli',
-            hostname: os.hostname(),
-            openBrowser: true,
-            isJson: false,
-        });
-        if (!result.ok) {
-            return { mode: 'remote', oidc, method, ok: false };
+        // here.
+        //
+        // client_id (#833): send the DEVICE-flow client id (`OIDC_DEVICE_CLIENT_ID`,
+        // default `'wft-cli'`), NOT the IdP's `OIDC_CLIENT_ID`. The server validates
+        // it against its own `OIDC_DEVICE_CLIENT_ID` (also defaulting to `'wft-cli'`),
+        // so the stock CLI matches a stock server out of the box.
+        let deviceOk = false;
+        try {
+            const result = await deviceLogin({
+                baseUrl,
+                clientId: process.env['OIDC_DEVICE_CLIENT_ID'] ?? 'wft-cli',
+                hostname: os.hostname(),
+                openBrowser: true,
+                isJson: false,
+            });
+            deviceOk = result.ok;
+            if (!deviceOk) {
+                log('Browser/device login did not complete; falling back to manual PAT entry.');
+            }
+        }
+        catch (err) {
+            // #833: device/code can hard-reject (e.g. a client_id mismatch →
+            // `invalid_client`) or the network can fail. Don't crash setup — degrade
+            // to manual personal-access-token entry so onboarding can still finish.
+            const message = err instanceof Error ? err.message : String(err);
+            log(`Browser/device login could not start (${message}).`);
+            log('Falling back to manual personal-access-token entry.');
+        }
+        if (deviceOk) {
+            // Device login succeeded and the PAT is already persisted in the
+            // credentials file. Now write the URL-only remote MCP entry (#810) into
+            // ~/.claude.json. The entry carries ONLY WFT_API_URL — the bridge resolves
+            // its bearer token at runtime from the credentials file the device flow
+            // just wrote, so NO token is ever embedded in claude.json and NO PAT is
+            // double-cached here.
+            const setup = writeRemoteMcpEntryOnly({ ...options, remote: baseUrl });
+            return { mode: 'remote', oidc, method, ok: true, setup };
         }
-        // Device login succeeded and the PAT is already persisted in the
-        // credentials file. Now write the URL-only remote MCP entry (#810) into
-        // ~/.claude.json. The entry carries ONLY WFT_API_URL — the bridge resolves
-        // its bearer token at runtime from the credentials file the device flow
-        // just wrote, so NO token is ever embedded in claude.json and NO PAT is
-        // double-cached here.
-        const setup = writeRemoteMcpEntryOnly({ ...options, remote: baseUrl });
-        return { mode: 'remote', oidc, method, ok: true, setup };
+        // Device flow unavailable/aborted → fall through to the manual-PAT path
+        // below (records the method actually used so the result reflects reality).
+        method = 'manual-pat';
     }
     // method === 'manual-pat' (task #809): obtain a PAT, validate it, and persist
     // it through the SAME credentials writer the device flow uses

package/dist/config/env.d.ts

@@ -79,6 +79,7 @@ export declare const configSchema: z.ZodObject<{
     OIDC_CLIENT_ID: z.ZodOptional<z.ZodString>;
     OIDC_CLIENT_SECRET: z.ZodOptional<z.ZodString>;
     OIDC_REDIRECT_URI: z.ZodOptional<z.ZodString>;
+    OIDC_DEVICE_CLIENT_ID: z.ZodDefault<z.ZodString>;
     OIDC_POST_LOGOUT_REDIRECT_URI: z.ZodOptional<z.ZodString>;
     OIDC_SCOPES: z.ZodDefault<z.ZodString>;
     OIDC_DISCOVERY_MAX_ATTEMPTS: z.ZodPipe<z.ZodDefault<z.ZodString>, z.ZodTransform<number, string>>;

package/dist/config/env.js

@@ -108,6 +108,16 @@ export const configSchema = z
     OIDC_CLIENT_ID: z.string().min(1).optional(),
     OIDC_CLIENT_SECRET: z.string().min(1).optional(),
     OIDC_REDIRECT_URI: z.string().url().optional(),
+    // RFC 8628 device-flow client_id (#833). DISTINCT from OIDC_CLIENT_ID: the
+    // latter is the IdP's OAuth client id used for the BROWSER SSO leg
+    // (`/auth/login` → Google), which is opaque to the CLI. The device-flow
+    // `client_id` is a logical identifier the CLI and server agree on out of
+    // band; the `tasks` CLI sends `'wft-cli'` by default. Conflating the two
+    // (the original Plan-30-08 wiring used OIDC_CLIENT_ID for both) made the
+    // device flow reject the CLI's default `client_id` with `invalid_client`
+    // on any server backed by a real IdP. Defaulted so it works with the
+    // stock CLI and is NOT part of the all-or-nothing OIDC group.
+    OIDC_DEVICE_CLIENT_ID: z.string().min(1).default('wft-cli'),
     // WR-03 fix — `post_logout_redirect_uri` for RP-initiated logout.
     // Optional: when absent, the wiring at src/api/server.ts derives a
     // default from OIDC_REDIRECT_URI's origin (+ `/auth/login`). Sourcing

package/docs/SETUP.md

@@ -332,6 +332,14 @@ OIDC_REDIRECT_URI=http://localhost:3000/auth/callback
 # Optional — defaults to "openid email profile". The server requires at
 # minimum "openid email" to map the OIDC subject to a local user row.
 OIDC_SCOPES=openid email profile
+
+# Optional — defaults to "wft-cli". The RFC 8628 device-flow client_id the
+# `tasks` CLI sends during `tasks setup` → Remote. DISTINCT from OIDC_CLIENT_ID
+# (the IdP's OAuth client id for the browser SSO leg): the device flow uses a
+# logical client id the CLI and server agree on. Leave unset on both sides to
+# use the default — the stock CLI then authenticates out of the box. Override
+# only if you also set OIDC_DEVICE_CLIENT_ID to a matching value on the client.
+OIDC_DEVICE_CLIENT_ID=wft-cli
 ```
 
 ### 3. Generate the session cookie secret

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wood-fired-tasks",
-  "version": "2.0.1",
+  "version": "2.0.3",
   "description": "Network-wide task tracking system for Wood Fired Games",
   "keywords": [
     "task-tracker",