@rikaidev/yomi 0.4.0 → 0.4.1

package/PRIVACY.md

@@ -19,6 +19,20 @@ The only data that leaves your device is whatever the agent surfaces in its
 replies to you — and in a cloud assistant, that surfaced text is processed by
 that assistant's model. Yomi itself makes no outbound copy of your messages.
 
+## The one non-LINE request Yomi makes
+
+At startup Yomi asks the public npm registry whether a newer version has been
+published, and tells the agent if so. This exists because a Desktop Extension
+(`.mcpb`) installed by hand never auto-updates — without the check you could
+sit on an old build, security fixes included, and never know.
+
+It sends **no message content and no account identifier**: it is a plain GET of
+a public package document. What it does reveal to the registry is that your IP
+address is running Yomi, and roughly which version. Nothing is uploaded.
+
+Set **`YOMI_NO_UPDATE_CHECK=1`** to turn it off; Yomi then makes no outbound
+request except to LINE itself.
+
 ## Excluding conversations
 
 You can exclude any conversation at any time, in plain language to the agent

package/dist/auth/credential-store.js

@@ -16,6 +16,15 @@
  * KeychainService service name: see keychain.ts — writes go to Yomi's own
  * canonical namespace; a legacy namespace from before this split is read
  * as a fallback and migrated forward, never written to or deleted.
+ *
+ * The Keychain is machine-global: it is NOT scoped by YOMI_DATA_DIR, so on
+ * macOS an automated run that only redirected the data dir would still find —
+ * and act on — the developer's real LINE session (a stored login certificate
+ * is enough for `login` to start a device sign-in against the live account).
+ * `YOMI_NO_KEYCHAIN=1` forces the file backend so tests and smoke runs are
+ * genuinely isolated by pointing YOMI_DATA_DIR somewhere disposable. It is a
+ * testing escape hatch: setting it in normal use downgrades credential
+ * storage from the Keychain to a plain JSON file.
  */
 import { dirname, join } from 'node:path';
 import { getKeychainService } from './keychain.js';
@@ -188,7 +197,8 @@ export class CredentialStore {
         this.filePath = fallbackFilePath;
         this.cache = new Map();
         this.loaded = false;
-        this.secureStorageEnabled = process.platform === 'darwin';
+        this.secureStorageEnabled =
+            process.platform === 'darwin' && process.env.YOMI_NO_KEYCHAIN !== '1';
         this.keychainService = this.secureStorageEnabled
             ? getKeychainService()
             : null;

package/dist/mcp/client-capabilities.js

@@ -0,0 +1,55 @@
+import { CLIENT_CAPABILITIES_META_KEY } from '@modelcontextprotocol/server';
+/**
+ * The capabilities the CURRENT request's client declared.
+ *
+ * @param server - MCP Server instance (the legacy, handshake-scoped source).
+ * @param ctx - Request handler context (the modern, per-request source).
+ * @returns The declared capabilities, or undefined when the client declared
+ * none and no envelope carried any.
+ */
+export function clientCapabilitiesOf(server, ctx) {
+    // The envelope type is opaque (`RequestMetaEnvelope = {}`) — the SDK models
+    // it as a bag of reserved keys, so reaching the declared capabilities off it
+    // needs an index-signature view rather than a property access.
+    const envelope = ctx?.mcpReq.envelope;
+    return (envelope?.[CLIENT_CAPABILITIES_META_KEY] ?? server.getClientCapabilities());
+}
+/**
+ * Does the connected client accept form-mode elicitation (`elicitation/create`
+ * carrying a `requestedSchema`)?
+ *
+ * @param capabilities - Result of `server.getClientCapabilities()`.
+ * @returns True when the client declared `elicitation.form`, or declared a
+ * bare `elicitation` with no mode sub-keys at all (pre-2026-07-28 shape).
+ */
+export function supportsFormElicitation(capabilities) {
+    const elicitation = capabilities?.elicitation;
+    if (!elicitation || typeof elicitation !== 'object') {
+        return false;
+    }
+    if ('form' in elicitation && elicitation.form) {
+        return true;
+    }
+    // A client that named `url` and not `form` is url-only; one that named
+    // neither predates the split and can only have meant form.
+    return !('url' in elicitation && elicitation.url);
+}
+/**
+ * Does the connected client accept url-mode elicitation (`elicitation/create`
+ * with `mode: "url"`, answered out-of-band and closed by a
+ * `notifications/elicitation/complete`)?
+ *
+ * Not used by any flow yet — url mode has no observed client support, the
+ * same trap ./ui/login-app.ts documents for MCP Apps. Exported so a future
+ * url-mode path can gate on the real declaration rather than assume it.
+ *
+ * @param capabilities - Result of `server.getClientCapabilities()`.
+ * @returns True only when the client explicitly declared `elicitation.url`.
+ */
+export function supportsUrlElicitation(capabilities) {
+    const elicitation = capabilities?.elicitation;
+    if (!elicitation || typeof elicitation !== 'object') {
+        return false;
+    }
+    return 'url' in elicitation && Boolean(elicitation.url);
+}

package/dist/mcp/handlers/login-copy.js

@@ -0,0 +1,200 @@
+import { LINE_PIN_CODE_LIFETIME_MS } from '../../line/auth/pwless/index.js';
+/** LINE region codes offered on the login form. */
+export const LOGIN_REGIONS = ['TW', 'JP', 'TH', 'ID', 'US'];
+/** Where the toggle lives on the primary phone, in LINE's own words. */
+export const PRIMARY_DEVICE_SETTING_PATH = '設定 > 我的帳號 > 允許自其他裝置登入';
+/**
+ * The prerequisite as a single line, for texts that report on a login
+ * already in flight (the PIN and cert steps) rather than gating one.
+ */
+const PRIMARY_DEVICE_SETTING_NOTE = `0. This only works if the primary phone has ${PRIMARY_DEVICE_SETTING_PATH} ` +
+    '(Settings > Account > allow logging in from other devices; the label is ' +
+    'localized) enabled — without it LINE will not offer this device a sign-in ' +
+    'prompt at all.\n';
+/**
+ * Step-by-step instructions for turning the setting on, returned when the
+ * human says it is off or that they do not know where it is.
+ */
+const PRIMARY_DEVICE_SETTING_STEPS = 'On the PRIMARY phone (the one already logged in to this LINE account):\n\n' +
+    '1. Open LINE and go to the 主頁 / Home tab.\n' +
+    '2. Tap the gear icon in the top corner to open 設定 (Settings).\n' +
+    '3. Open 我的帳號 (Account).\n' +
+    '4. Turn ON 允許自其他裝置登入 (the toggle allowing login from other ' +
+    'devices — the exact wording is localized).\n\n' +
+    'This toggle is what lets LINE prompt a second device to sign in. With it ' +
+    'off, nothing at all appears on the phone and the login simply never ' +
+    'completes.';
+/** Answers offered by the pre-flight prerequisite check. */
+const PREREQ_ANSWERS = {
+    enabled: 'enabled',
+    notEnabled: 'not_enabled',
+    unsure: 'unsure',
+};
+/**
+ * The prerequisite question, in the 2026-07-28 `oneOf`-with-`title`
+ * single-select shape (`TitledSingleSelectEnumSchema`) so each choice carries
+ * human-facing text of its own, rather than an enum of bare machine values
+ * the client has to render raw.
+ */
+const PREREQ_SCHEMA_PROPERTY = {
+    type: 'string',
+    title: 'Is 允許自其他裝置登入 enabled on your primary phone?',
+    description: `On the phone already logged in to LINE: ${PRIMARY_DEVICE_SETTING_PATH}. ` +
+        'Without it, LINE never prompts this device and the login cannot finish.',
+    oneOf: [
+        { const: PREREQ_ANSWERS.enabled, title: 'Yes — it is already on' },
+        { const: PREREQ_ANSWERS.notEnabled, title: 'No / not yet — show me how' },
+        {
+            const: PREREQ_ANSWERS.unsure,
+            title: "I don't know where that setting is",
+        },
+    ],
+};
+/**
+ * Build the one form shown before a login starts: the prerequisite, plus
+ * `phone`/`region` when the caller did not supply them.
+ *
+ * Both live in ONE form on purpose — the human answers a single prompt, and
+ * the prerequisite is raised while it can still change the outcome.
+ *
+ * @param phone - Phone already supplied by the tool call, if any.
+ * @param region - Region already supplied by the tool call, if any.
+ * @returns The elicitation body, for `elicitInput` or `inputRequired.elicit`.
+ */
+export function buildPreflightForm(phone, region) {
+    const needsCredentials = !phone || !region;
+    const properties = {
+        primaryDeviceLogin: PREREQ_SCHEMA_PROPERTY,
+    };
+    const required = ['primaryDeviceLogin'];
+    if (needsCredentials) {
+        properties.phone = {
+            type: 'string',
+            title: 'Phone number',
+            description: 'E.164 form, e.g. +8869XXXXXXXX.',
+            ...(phone ? { default: phone } : {}),
+        };
+        properties.region = {
+            type: 'string',
+            title: 'Region',
+            enum: LOGIN_REGIONS,
+            ...(region ? { default: region } : {}),
+        };
+        required.push('phone', 'region');
+    }
+    return {
+        message: 'Yomi signs in as a SECOND LINE device. That requires ' +
+            `${PRIMARY_DEVICE_SETTING_PATH} to be enabled on the phone already ` +
+            'logged in — confirm that below' +
+            (needsCredentials
+                ? ', along with your number and region.'
+                : ' before the login starts.'),
+        requestedSchema: { type: 'object', properties, required },
+    };
+}
+/**
+ * Read an accepted pre-flight form back. Shared by every path so the answer
+ * is interpreted identically no matter how it was collected.
+ *
+ * @param content - The accepted form content (untrusted client input).
+ * @param phone - Phone supplied by the tool call, used when the form did not
+ * carry the field because it was already known.
+ * @param region - Region, same rule.
+ * @returns What the login should do next.
+ */
+export function readPreflightForm(content, phone, region) {
+    const answer = String(content?.primaryDeviceLogin ?? '');
+    if (answer !== PREREQ_ANSWERS.enabled) {
+        return { ok: false, reason: 'prerequisite', answer };
+    }
+    const collectedPhone = String(content?.phone ?? phone ?? '');
+    const collectedRegion = String(content?.region ?? region ?? '');
+    if (!collectedPhone || !collectedRegion) {
+        return { ok: false, reason: 'cancelled' };
+    }
+    return { ok: true, phone: collectedPhone, region: collectedRegion };
+}
+/**
+ * The numbered steps for acting on an issued PIN. Step 0 repeats the
+ * prerequisite even though the pre-flight form already asked about it: a
+ * human who answered "yes" without checking finds out here, while the code
+ * is still valid.
+ *
+ * @param pin - The PIN LINE just issued.
+ * @returns The steps, ending in a blank line.
+ */
+export function pinSteps(pin) {
+    const lifetimeSeconds = Math.round(LINE_PIN_CODE_LIFETIME_MS / 1000);
+    return (`LINE PIN:\n\n    ${pin}\n\n` +
+        PRIMARY_DEVICE_SETTING_NOTE +
+        '1. Open LINE on the primary phone. If a verification prompt does not ' +
+        'appear immediately, bringing the app to the foreground surfaces it.\n' +
+        `2. Enter this PIN and tick the device that is signing in, then tap ` +
+        `「用戶確認」 — LINE gives you ${lifetimeSeconds} seconds (about 3 ` +
+        'minutes) from when the code was shown to do this.\n' +
+        '3. LINE will then ask that same phone to approve this new device ' +
+        'signing in — approve it there.\n\n');
+}
+/**
+ * The steps when a stored login certificate skipped the PIN entirely — the
+ * flow is already waiting on phone approval of this device.
+ *
+ * @returns The steps, ending in a blank line.
+ */
+export function certSteps() {
+    return ('No PIN needed — LINE recognized a stored login certificate from a ' +
+        'previous login, so the PIN step was skipped.\n\n' +
+        PRIMARY_DEVICE_SETTING_NOTE +
+        '1. Bring the LINE app to the foreground on your primary phone — it ' +
+        'should prompt you to approve this new device signing in.\n' +
+        '2. Approve the device from there.\n\n');
+}
+/**
+ * The acknowledgement form shown alongside an issued PIN (or alongside the
+ * cert-skipped approval prompt).
+ *
+ * @param pin - The PIN, or `null` when a stored certificate skipped it.
+ * @returns The elicitation body.
+ */
+export function buildAcknowledgementForm(pin) {
+    return {
+        message: (pin ? pinSteps(pin) : certSteps()) +
+            'Acknowledge below once you have done this.',
+        requestedSchema: {
+            type: 'object',
+            properties: {
+                entered: {
+                    type: 'boolean',
+                    title: pin
+                        ? 'I entered the PIN and approved the device on my phone'
+                        : 'I approved the device on my phone',
+                },
+            },
+        },
+    };
+}
+/**
+ * Build the tool result returned when the human has not confirmed the
+ * prerequisite. Deliberately NOT a tool error: nothing failed, the login was
+ * simply never started, and the human has one concrete thing to do.
+ *
+ * @param answer - Which non-confirming answer they gave, for wording.
+ * @returns MCP tool result carrying the enabling steps and the retry.
+ */
+export function prerequisiteNotMetResult(answer) {
+    const lead = answer === PREREQ_ANSWERS.unsure
+        ? 'Login was not started — here is where that setting lives.\n\n'
+        : 'Login was not started, because LINE would never prompt the phone.\n\n';
+    return {
+        content: [
+            {
+                type: 'text',
+                text: lead +
+                    PRIMARY_DEVICE_SETTING_STEPS +
+                    '\n\nOnce the toggle is on, call `login` again. Relay these steps ' +
+                    'to the human as they are — do not summarize the settings path ' +
+                    'away, it is the whole point.',
+            },
+        ],
+    };
+}

package/dist/mcp/handlers/login-mrtr.js

@@ -0,0 +1,150 @@
+/**
+ * `login` on a MCP 2026-07-28 connection: the multi-round-trip (MRTR) path.
+ *
+ * That revision removed the server→client request channel — `elicitInput`
+ * throws on a modern-era instance before any wire traffic (SDK:
+ * `_assertPushApiInServedEra`, "the 2026-07-28 revision has no server→client
+ * request channel"). The same conversation is instead carried by
+ * `input_required` RESULTS: the handler returns the elicitation it needs,
+ * the client fulfils it through its own `elicitation/create` handler, then
+ * RE-CALLS `login` with the answers in `inputResponses`.
+ *
+ * So this file is ./login.ts's pushed elicitation flow turned inside out —
+ * same three beats, one tool call each:
+ *
+ *   round 1  no responses          → ask the pre-flight form
+ *   round 2  `preflight` answered  → start the login, ask for PIN ack
+ *   round 3  `ack` answered        → await completion, return the profile
+ *
+ * The in-flight login survives between rounds in ./login-session.ts, exactly
+ * as it survives between `login` and `login_complete` on the fallback path.
+ *
+ * `requestState` (the other half of MRTR) is deliberately NOT used: it
+ * round-trips through the client and comes back attacker-controlled, so the
+ * spec requires integrity-protecting anything that influences behavior. The
+ * only state this flow needs is the pending login, which never leaves the
+ * server.
+ */
+import { acceptedContent, inputRequired, inputResponse, } from '@modelcontextprotocol/server';
+import { createCliLogger } from '../../util/log.js';
+import { buildAcknowledgementForm, buildPreflightForm, prerequisiteNotMetResult, readPreflightForm, } from './login-copy.js';
+import { finishPendingLogin, getLivePendingLogin, getPendingLogin, PIN_WAIT_TIMEOUT_MS, startPendingLogin, waitForPin, } from './login-session.js';
+import { jsonText, toolError } from './shared.js';
+const log = createCliLogger('Yomi');
+/** Keys this flow assigns to its embedded input requests. */
+const PREFLIGHT_KEY = 'preflight';
+const ACK_KEY = 'ack';
+/**
+ * Round 3 — the human says they have acted on their phone. Await the login
+ * `startPendingLogin` began in round 2.
+ *
+ * @returns The logged-in profile, or an honest error.
+ */
+async function completeRound() {
+    const pending = getPendingLogin();
+    if (!pending) {
+        return toolError('No login is pending — the attempt this acknowledgement belongs to has already finished or ' +
+            'expired (LINE gives the human about 3 minutes to act on a shown code). Calling `login` ' +
+            'again is safe and starts a fresh attempt.');
+    }
+    try {
+        const { mid, displayName } = await finishPendingLogin(pending);
+        return {
+            content: [
+                {
+                    type: 'text',
+                    text: jsonText({ loggedIn: true, mid, displayName }),
+                },
+            ],
+        };
+    }
+    catch (error) {
+        return toolError(error?.message ?? String(error));
+    }
+}
+/**
+ * Round 2 — the pre-flight form came back accepted and confirming. Start
+ * (or reuse) the passwordless login and ask the human to act on the PIN.
+ *
+ * @param service - LineProtocolService (not yet authenticated).
+ * @param phone - Confirmed phone number.
+ * @param region - Confirmed region code.
+ * @returns An `input_required` result carrying the PIN acknowledgement form,
+ * or an honest error.
+ */
+async function startRound(service, phone, region) {
+    const active = getLivePendingLogin(Date.now());
+    if (active && (active.phone !== phone || active.region !== region)) {
+        // A live login for a DIFFERENT number is still in flight. Never hand
+        // back its PIN under this call's identity. Name nothing sensitive.
+        return toolError('A login for a different phone number is still in progress. Wait for its login code to expire ' +
+            '(LINE gives the human about 3 minutes to act on it) before starting a login for another number.');
+    }
+    const pending = active ?? startPendingLogin(service, phone, region);
+    const pin = await waitForPin(pending, PIN_WAIT_TIMEOUT_MS);
+    if (!pin && !pending.certSkippedPin) {
+        return toolError('LINE has not issued a login PIN within 20s. The attempt is still running in the background ' +
+            '(do not worry, nothing was lost) — call `login` again shortly to check for the PIN.');
+    }
+    log.warn('login.pin', {
+        action: pin ? 'returned_in_input_required' : 'skipped_cert_valid',
+    });
+    // The PIN travels inside the elicitation the client is about to render,
+    // and the login keeps running while the human acts on it — this handler
+    // returns immediately rather than blocking through LINE's ~3-minute
+    // window, so the human's clock starts now and not after a timeout.
+    return inputRequired({
+        inputRequests: {
+            [ACK_KEY]: inputRequired.elicit(buildAcknowledgementForm(pin)),
+        },
+    });
+}
+/**
+ * Handle `login` on a modern-era connection. Which round this call is comes
+ * from the responses it carries: none means round 1.
+ *
+ * @param service - LineProtocolService (not yet authenticated).
+ * @param args - Tool arguments.
+ * @param inputResponses - `ctx.mcpReq.inputResponses` from a retried call.
+ * Untrusted client input — read only through the SDK's response readers.
+ * @returns An `input_required` result, or a terminal tool result.
+ */
+export async function handleLoginMrtr(service, args, inputResponses) {
+    // Round 3 first: a client that accumulates responses across rounds would
+    // send both keys, and the later beat is the one to act on.
+    const ack = inputResponse(inputResponses, ACK_KEY);
+    if (ack.kind === 'elicit') {
+        if (ack.action !== 'accept') {
+            return toolError('Login was cancelled by the user.');
+        }
+        return await completeRound();
+    }
+    const preflight = inputResponse(inputResponses, PREFLIGHT_KEY);
+    if (preflight.kind === 'elicit') {
+        if (preflight.action !== 'accept') {
+            return toolError('Login was cancelled by the user.');
+        }
+        const outcome = readPreflightForm(acceptedContent(inputResponses, PREFLIGHT_KEY), args.phone, args.region);
+        if (!outcome.ok) {
+            if (outcome.reason === 'prerequisite') {
+                log.warn('login.prerequisite', { answer: outcome.answer });
+                return prerequisiteNotMetResult(outcome.answer);
+            }
+            return toolError('Login was cancelled by the user.');
+        }
+        return await startRound(service, outcome.phone, outcome.region);
+    }
+    // Round 1. Persisted credentials still pre-fill the form, so a returning
+    // user only confirms rather than retypes.
+    const phone = args.phone ??
+        (await service.credentialStore?.get?.('line_phone')) ??
+        undefined;
+    const region = args.region ??
+        (await service.credentialStore?.get?.('line_region')) ??
+        undefined;
+    return inputRequired({
+        inputRequests: {
+            [PREFLIGHT_KEY]: inputRequired.elicit(buildPreflightForm(phone, region)),
+        },
+    });
+}

package/dist/mcp/handlers/login-session.js

@@ -0,0 +1,132 @@
+import { runPwlessLogin } from '../../cli/login.js';
+import { LINE_PIN_CODE_LIFETIME_MS } from '../../line/auth/pwless/index.js';
+import { createCliLogger } from '../../util/log.js';
+const log = createCliLogger('Yomi');
+/**
+ * How long a live pending login may be reused by a later `login` call for
+ * the same phone/region, before treating it as stale and starting fresh.
+ *
+ * This is bound to LINE's real PIN code lifetime (~line/auth/pwless/index.ts,
+ * an external fact from LINE Help Center, ~3 minutes) — NOT to how long
+ * yomi's client is willing to keep polling (~16 minutes). A login started
+ * 90 seconds ago is still very much alive and its PIN is still valid; the
+ * only thing that actually kills a pending login early is LINE's own code
+ * expiring, so that is the correct bound for "is this still worth reusing".
+ */
+const PIN_WINDOW_MS = LINE_PIN_CODE_LIFETIME_MS;
+/** How long a `login` call waits for LINE to issue a PIN before giving up. */
+export const PIN_WAIT_TIMEOUT_MS = 20000;
+let pendingLogin = null;
+/** @returns The in-flight login, or null when none is pending. */
+export function getPendingLogin() {
+    return pendingLogin;
+}
+/**
+ * The in-flight login only if it is still worth reusing: started within
+ * LINE's PIN lifetime.
+ *
+ * @param now - Current epoch millis.
+ * @returns The live pending login, or null.
+ */
+export function getLivePendingLogin(now) {
+    if (!pendingLogin) {
+        return null;
+    }
+    return now - pendingLogin.startedAt < PIN_WINDOW_MS ? pendingLogin : null;
+}
+/**
+ * Start a new passwordless login in the background and register it as the
+ * one in-flight pending login.
+ *
+ * The stored promise is the actual `runPwlessLogin` promise, so a later call
+ * can await it and see the real success/failure. A `.catch()` is attached
+ * immediately (its result discarded, not stored) so an abandoned login — one
+ * nobody ever finishes — never surfaces as an unhandled rejection; this does
+ * not affect what `promise` itself resolves/rejects with.
+ *
+ * @param service - LineProtocolService (not yet authenticated).
+ * @param phone - Phone number in E.164 form.
+ * @param region - Region code.
+ * @returns The newly registered pending-login record.
+ */
+export function startPendingLogin(service, phone, region) {
+    let resolvePinReady = () => { };
+    const pinReady = new Promise((resolve) => {
+        resolvePinReady = resolve;
+    });
+    const pending = {
+        phone,
+        region,
+        pin: null,
+        certSkippedPin: false,
+        startedAt: Date.now(),
+        pinReady,
+    };
+    const onPin = (pin) => {
+        pending.pin = pin;
+        resolvePinReady();
+    };
+    const onBiometric = () => {
+        log.warn('login.waiting_biometric', {
+            action: 'approve the new device on your phone',
+        });
+        // Reaching biometric wait with no PIN ever set means a valid stored
+        // certificate skipped the PIN step entirely (see LinePwlessLogin.login,
+        // step 2-3) — resolve `pinReady` now so `waitForPin` doesn't block out
+        // its full timeout waiting for a PIN that will never arrive.
+        if (!pending.pin) {
+            pending.certSkippedPin = true;
+            resolvePinReady();
+        }
+    };
+    const promise = runPwlessLogin(service, phone, region, {
+        onPin,
+        onWaitingBiometric: onBiometric,
+    });
+    promise.catch(() => {
+        // Swallow here only to prevent an unhandled-rejection warning for a
+        // login nobody completes; the real error still surfaces to whoever
+        // awaits `promise` below.
+    });
+    pending.promise = promise;
+    pendingLogin = pending;
+    return pendingLogin;
+}
+/**
+ * Wait for a pending login's PIN to arrive, bounded by a timeout.
+ *
+ * @param pending - The pending login to wait on.
+ * @param timeoutMs - Maximum time to wait.
+ * @returns The PIN, or `null` if it did not arrive within `timeoutMs` (also
+ * the answer when a stored certificate skipped the PIN — check
+ * `certSkippedPin` to tell the two apart).
+ */
+export async function waitForPin(pending, timeoutMs) {
+    if (pending.pin) {
+        return pending.pin;
+    }
+    return await Promise.race([
+        pending.pinReady.then(() => pending.pin ?? null),
+        new Promise((resolve) => {
+            setTimeout(() => resolve(null), timeoutMs);
+        }),
+    ]);
+}
+/**
+ * Await the in-flight login to completion and clear it either way. Never
+ * touches credentials on the failure path — `runPwlessLogin` owns that.
+ *
+ * @param pending - The pending login to finish.
+ * @returns The logged-in profile.
+ * @throws Whatever `runPwlessLogin` failed with.
+ */
+export async function finishPendingLogin(pending) {
+    try {
+        const result = await pending.promise;
+        log.info('login.complete', { mid: result.mid });
+        return result;
+    }
+    finally {
+        pendingLogin = null;
+    }
+}

package/dist/mcp/handlers/login.js

@@ -1,78 +1,24 @@
 import { runPwlessLogin } from '../../cli/login.js';
 import { LINE_PIN_CODE_LIFETIME_MS, PAAK_AUTH_CLIENT_CEILING_MS, PIN_VERIFY_CLIENT_CEILING_MS, } from '../../line/auth/pwless/index.js';
 import { createCliLogger } from '../../util/log.js';
+import { supportsFormElicitation } from '../client-capabilities.js';
 import { supportsMcpApps } from '../ui/capability.js';
+import { buildAcknowledgementForm, buildPreflightForm, certSteps, LOGIN_REGIONS, PRIMARY_DEVICE_SETTING_PATH, pinSteps, prerequisiteNotMetResult, readPreflightForm, } from './login-copy.js';
+import { handleLoginMrtr } from './login-mrtr.js';
+import { finishPendingLogin, getLivePendingLogin, getPendingLogin, PIN_WAIT_TIMEOUT_MS, startPendingLogin, waitForPin, } from './login-session.js';
 import { jsonText, toolError } from './shared.js';
 const log = createCliLogger('Yomi');
-/** LINE region codes offered on the login elicitation form. */
-const LOGIN_REGIONS = ['TW', 'JP', 'TH', 'ID', 'US'];
-/**
- * How long a live `pendingLogin` may be reused by a later `login` call for
- * the same phone/region, before treating it as stale and starting fresh.
- *
- * This is bound to LINE's real PIN code lifetime (~line/auth/pwless/index.ts,
- * an external fact from LINE Help Center, ~3 minutes) — NOT to how long
- * yomi's client is willing to keep polling (~16 minutes). A login started
- * 90 seconds ago is still very much alive and its PIN is still valid; the
- * only thing that actually kills a pending login early is LINE's own code
- * expiring, so that is the correct bound for "is this still worth reusing".
- */
-const PIN_WINDOW_MS = LINE_PIN_CODE_LIFETIME_MS;
 /**
  * How long yomi's client keeps polling for the device-approval step once a
  * PIN has been verified (or skipped via a stored certificate) — the real
- * ceiling `login_complete` blocks for, used only to describe that wait to
+ * ceiling the completing call blocks for, used only to describe that wait to
  * the human, not to bound anything server-side.
  */
 const APPROVAL_WINDOW_MS = PAAK_AUTH_CLIENT_CEILING_MS;
-/** How long `login` waits for LINE to issue a PIN before reporting a failure. */
-const PIN_WAIT_TIMEOUT_MS = 20000;
-/**
- * Elicit `phone`/`region` from the human in one form, pre-filling whatever
- * the caller already supplied.
- *
- * @param server - MCP Server instance (elicitation already capability-gated
- * by the caller).
- * @param phone - Phone already supplied by the tool call, if any.
- * @param region - Region already supplied by the tool call, if any.
- * @returns The collected phone/region, or `null` if the human declined/cancelled.
- */
-async function elicitPhoneRegion(server, phone, region) {
-    const collected = await server.elicitInput({
-        message: 'Yomi needs your LINE phone number and region to start passwordless login.',
-        requestedSchema: {
-            type: 'object',
-            properties: {
-                phone: {
-                    type: 'string',
-                    title: 'Phone number',
-                    description: 'E.164 form, e.g. +8869XXXXXXXX.',
-                    ...(phone ? { default: phone } : {}),
-                },
-                region: {
-                    type: 'string',
-                    title: 'Region',
-                    enum: LOGIN_REGIONS,
-                    ...(region ? { default: region } : {}),
-                },
-            },
-            required: ['phone', 'region'],
-        },
-    });
-    if (collected.action !== 'accept') {
-        return null;
-    }
-    const collectedPhone = String(collected.content?.phone ?? '');
-    const collectedRegion = String(collected.content?.region ?? '');
-    if (!collectedPhone || !collectedRegion) {
-        return null;
-    }
-    return { phone: collectedPhone, region: collectedRegion };
-}
 /**
  * Elicit acknowledgement of the login PIN — fire-and-forget from the
- * caller's perspective (must not block `startPwlessLogin`, which is
- * already running concurrently and waiting on phone biometric approval).
+ * caller's perspective (must not block `runPwlessLogin`, which is already
+ * running concurrently and waiting on phone biometric approval).
  *
  * @param server - MCP Server instance.
  * @param pin - The PIN LINE just issued.
@@ -82,19 +28,7 @@ async function elicitPhoneRegion(server, phone, region) {
  */
 function elicitPinAcknowledgement(server, pin, onDeclined) {
     server
-        .elicitInput({
-        message: `LINE PIN: ${pin}\n\nEnter this PIN in the LINE app on your primary phone, then approve ` +
-            'the new device from there. Acknowledge below once you have done this.',
-        requestedSchema: {
-            type: 'object',
-            properties: {
-                entered: {
-                    type: 'boolean',
-                    title: 'I entered the PIN and approved the device on my phone',
-                },
-            },
-        },
-    })
+        .elicitInput(buildAcknowledgementForm(pin))
         .then((result) => {
         if (result.action !== 'accept') {
             onDeclined();
@@ -107,12 +41,13 @@ function elicitPinAcknowledgement(server, pin, onDeclined) {
     });
 }
 /**
- * Handle `login` for a client that supports MCP elicitation — drive the
- * passwordless flow entirely through elicitation, with no out-of-band
- * channel required. Phone/region are elicited when missing, and the PIN is
+ * Handle `login` on a LEGACY-era connection whose client supports form
+ * elicitation — drive the passwordless flow entirely through pushed
+ * elicitation requests, with no out-of-band channel required. A pre-flight
+ * form confirms the 允許自其他裝置登入 prerequisite (and collects
+ * phone/region when missing) BEFORE any PIN is issued; the PIN is then
  * surfaced through a second elicitation fired without blocking
- * `startPwlessLogin`, which keeps running while the human acts on their
- * phone. See ../cli/login.ts for the shared login sequence.
+ * `runPwlessLogin`, which keeps running while the human acts on their phone.
  *
  * @param server - MCP Server instance (for elicitInput).
  * @param service - LineProtocolService (not yet authenticated).
@@ -120,15 +55,19 @@ function elicitPinAcknowledgement(server, pin, onDeclined) {
  * @returns MCP tool result describing the logged-in profile.
  */
 async function handleLoginElicitation(server, service, args) {
-    let { phone, region } = args;
-    if (!phone || !region) {
-        const collected = await elicitPhoneRegion(server, phone, region);
-        if (!collected) {
-            return toolError('Login was cancelled by the user.');
+    const collected = await server.elicitInput(buildPreflightForm(args.phone, args.region));
+    if (collected.action !== 'accept') {
+        return toolError('Login was cancelled by the user.');
+    }
+    const preflight = readPreflightForm(collected.content, args.phone, args.region);
+    if (!preflight.ok) {
+        if (preflight.reason === 'prerequisite') {
+            log.warn('login.prerequisite', { answer: preflight.answer });
+            return prerequisiteNotMetResult(preflight.answer);
         }
-        ;
-        ({ phone, region } = collected);
+        return toolError('Login was cancelled by the user.');
     }
+    const { phone, region } = preflight;
     let pinDeclined = false;
     const onPin = (pin) => {
         log.warn('login.pin', { action: 'elicit_acknowledgement' });
@@ -163,90 +102,12 @@ async function handleLoginElicitation(server, service, args) {
         return toolError(error?.message ?? String(error));
     }
 }
-let pendingLogin = null;
 /**
- * Start a new passwordless login in the background and register it as the
- * one in-flight pending login.
- *
- * The stored promise is the actual `runPwlessLogin` promise, so
- * `login_complete` can await it and see the real success/failure. A
- * `.catch()` is attached immediately (its result discarded, not stored) so
- * an abandoned login — one nobody ever calls `login_complete` for — never
- * surfaces as an unhandled rejection; this does not affect what
- * `pendingLogin.promise` itself resolves/rejects with.
- *
- * @param service - LineProtocolService (not yet authenticated).
- * @param phone - Phone number in E.164 form.
- * @param region - Region code.
- * @returns The newly registered pending-login record.
- */
-function startPendingLogin(service, phone, region) {
-    let resolvePinReady = () => { };
-    const pinReady = new Promise((resolve) => {
-        resolvePinReady = resolve;
-    });
-    const pending = {
-        phone,
-        region,
-        pin: null,
-        certSkippedPin: false,
-        startedAt: Date.now(),
-        pinReady,
-    };
-    const onPin = (pin) => {
-        pending.pin = pin;
-        resolvePinReady();
-    };
-    const onBiometric = () => {
-        log.warn('login.waiting_biometric', {
-            action: 'approve the new device on your phone',
-        });
-        // Reaching biometric wait with no PIN ever set means a valid stored
-        // certificate skipped the PIN step entirely (see LinePwlessLogin.login,
-        // step 2-3) — resolve `pinReady` now so `waitForPin` doesn't block out
-        // its full timeout waiting for a PIN that will never arrive.
-        if (!pending.pin) {
-            pending.certSkippedPin = true;
-            resolvePinReady();
-        }
-    };
-    const promise = runPwlessLogin(service, phone, region, {
-        onPin,
-        onWaitingBiometric: onBiometric,
-    });
-    promise.catch(() => {
-        // Swallow here only to prevent an unhandled-rejection warning for a
-        // login nobody completes; the real error still surfaces to whoever
-        // awaits `pending.promise` (login_complete) below.
-    });
-    pending.promise = promise;
-    return pending;
-}
-/**
- * Wait for a pending login's PIN to arrive, bounded by a timeout.
- *
- * @param pending - The pending login to wait on.
- * @param timeoutMs - Maximum time to wait.
- * @returns The PIN, or `null` if it did not arrive within `timeoutMs`.
- */
-async function waitForPin(pending, timeoutMs) {
-    if (pending.pin) {
-        return pending.pin;
-    }
-    const outcome = await Promise.race([
-        pending.pinReady.then(() => pending.pin ?? null),
-        new Promise((resolve) => {
-            setTimeout(() => resolve(null), timeoutMs);
-        }),
-    ]);
-    return outcome;
-}
-/**
- * Handle `login` for a client that does NOT support MCP elicitation
- * (confirmed empirically for Claude Desktop). Splits the flow into two
- * tool calls since the PIN cannot be prompted for in-band: this call
- * starts (or reuses) the passwordless flow and returns the PIN as soon as
- * LINE issues it; `login_complete` finishes it once the human has acted.
+ * Handle `login` for a client that supports no form of elicitation at all
+ * (confirmed empirically for Claude Desktop). Splits the flow into two tool
+ * calls since the PIN cannot be prompted for in-band: this call starts (or
+ * reuses) the passwordless flow and returns the PIN as soon as LINE issues
+ * it; `login_complete` finishes it once the human has acted.
  *
  * The MCP Apps view (./ui/login-app.ts) has never been observed to render on
  * any deployed client (see that file's header) — resources/read succeeds
@@ -297,6 +158,9 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
                         type: 'text',
                         text: 'Ask the human for their LINE phone number (E.164 form, e.g. +8869XXXXXXXX) and region ' +
                             `(one of ${LOGIN_REGIONS.join(', ')}), then call \`login\` again with those as arguments. ` +
+                            'In the same message, tell them yomi signs in as a SECOND device, which requires ' +
+                            `${PRIMARY_DEVICE_SETTING_PATH} to be enabled on the phone already logged in — if it is ` +
+                            'off, LINE never prompts that phone and the login cannot finish. ' +
                             'A login form may also appear for the human to fill in directly — if they use it, the ' +
                             'login proceeds on its own and there is nothing further for you to do — but do not wait ' +
                             'for that; if no form appears, asking the human directly is how this login makes progress.',
@@ -310,14 +174,13 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
             missing.push('phone');
         if (!region)
             missing.push('region');
-        return toolError(`Missing ${missing.join(' and ')} for login. This MCP client does not support elicitation, so ` +
+        return toolError(`Missing ${missing.join(' and ')} for login. This MCP client does not support form elicitation, so ` +
             `${missing.join('/')} must be supplied as a tool argument, or persisted by running ` +
-            '`npx @rikaidev/yomi login` once in a terminal.');
+            '`npx @rikaidev/yomi login` once in a terminal. Also tell the human that yomi signs in as a ' +
+            `SECOND device, which requires ${PRIMARY_DEVICE_SETTING_PATH} enabled on the phone already ` +
+            'logged in — with it off, LINE never prompts that phone and no login can succeed.');
     }
-    const now = Date.now();
-    const active = pendingLogin && now - pendingLogin.startedAt < PIN_WINDOW_MS
-        ? pendingLogin
-        : null;
+    const active = getLivePendingLogin(Date.now());
     if (active && (active.phone !== phone || active.region !== region)) {
         // A live login for a DIFFERENT number is still in flight. Never hand
         // back its PIN under this call's identity, and never silently start a
@@ -327,10 +190,8 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
             'before starting a login for another number.');
     }
     // Reuse the in-flight login only when it matches this number; otherwise
-    // start a fresh one. `pending` is non-null either way, so no narrowing of
-    // the module-level `pendingLogin` is needed downstream.
+    // start a fresh one.
     const pending = active ?? startPendingLogin(service, phone, region);
-    pendingLogin = pending;
     const pin = await waitForPin(pending, PIN_WAIT_TIMEOUT_MS);
     if (!pin) {
         if (pending.certSkippedPin) {
@@ -343,14 +204,7 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
                 pin: null,
                 clientApprovalPollCeilingSeconds: Math.round(APPROVAL_WINDOW_MS / 1000),
             };
-            const certSteps = 'No PIN needed — LINE recognized a stored login certificate from a previous login, ' +
-                'so the PIN step was skipped.\n\n' +
-                '0. This only works if the primary phone has 設定 > 我的帳號 > 允許自其他裝置登入 ' +
-                'enabled — without it LINE will not offer this device a sign-in prompt at all.\n' +
-                '1. Bring the LINE app to the foreground on your primary phone — it should prompt you ' +
-                'to approve this new device signing in.\n' +
-                '2. Approve the device from there.\n\n';
-            const certText = certSteps +
+            const certText = certSteps() +
                 'Call the `login_complete` tool (no arguments) IMMEDIATELY now — do not wait for ' +
                 'confirmation that the approval happened first. `login_complete` blocks by itself while ' +
                 `you approve (up to about ${Math.round(APPROVAL_WINDOW_MS / 60000)} minutes) and returns ` +
@@ -374,16 +228,7 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
         clientPinPollCeilingSeconds: Math.round(PIN_VERIFY_CLIENT_CEILING_MS / 1000),
         clientApprovalPollCeilingSeconds: Math.round(APPROVAL_WINDOW_MS / 1000),
     };
-    const pinSteps = 'LINE PIN:\n\n' +
-        `    ${pin}\n\n` +
-        '0. This only works if the primary phone has 設定 > 我的帳號 > 允許自其他裝置登入 enabled — ' +
-        'without it LINE will not offer this device a sign-in prompt at all.\n' +
-        '1. Open LINE on the primary phone. If a verification prompt does not appear immediately, ' +
-        'bringing the app to the foreground surfaces it.\n' +
-        `2. Enter this PIN and tick the device that is signing in, then tap 「用戶確認」 — LINE gives ` +
-        `you ${pinCodeLifetimeSeconds} seconds (about 3 minutes) from when the code was shown to do this.\n` +
-        '3. LINE will then ask that same phone to approve this new device signing in — approve it there.\n\n';
-    const pinText = pinSteps +
+    const pinText = pinSteps(pin) +
         `Call the \`login_complete\` tool (no arguments) IMMEDIATELY now — do not wait until you have ` +
         'entered the PIN or approved the device. `login_complete` blocks by itself through both of ' +
         `those steps: it keeps waiting up to about ${clientPinPollCeilingMinutes} minutes for step 2 and ` +
@@ -397,41 +242,50 @@ async function handleLoginNoElicitation(service, args, supportsUi) {
     };
 }
 /**
- * Handle `login` — dispatches to the elicitation flow when the connected
- * client supports it, otherwise the two-phase flow that finishes via
- * `login_complete`.
+ * Handle `login` — dispatches to the path the connected client can actually
+ * complete. See this module's header for the three paths.
  *
- * @param server - MCP Server instance (for elicitInput/getClientCapabilities).
+ * Elicitation is gated on the FORM sub-capability specifically, not on the
+ * presence of an `elicitation` object: since MCP 2026-07-28 a client may
+ * declare `elicitation: { url: {} }` alone, and both elicitation paths send
+ * a `requestedSchema` that such a client would reject. See
+ * ../client-capabilities.ts, which also owns WHERE the capabilities are read
+ * from — the accessor is empty on a modern-era stdio connection.
+ *
+ * @param server - MCP Server instance (for elicitInput on the legacy path).
  * @param service - LineProtocolService (not yet authenticated).
  * @param args - Tool arguments.
- * @returns MCP tool result.
+ * @param context - Era, client capabilities, and the multi-round-trip input
+ * responses a retried `tools/call` carried (`ctx.mcpReq.inputResponses`).
+ * @returns MCP tool result, or an `input_required` result on the MRTR path.
  */
-export async function handleLogin(server, service, args, capabilities = server.getClientCapabilities(), allowPushElicitation = true) {
-    if (allowPushElicitation && capabilities?.elicitation) {
-        return handleLoginElicitation(server, service, args);
+export async function handleLogin(server, service, args, context = {}) {
+    const { era = 'legacy', capabilities = server.getClientCapabilities(), inputResponses, } = context;
+    if (supportsFormElicitation(capabilities)) {
+        return era === 'legacy'
+            ? handleLoginElicitation(server, service, args)
+            : handleLoginMrtr(service, args, inputResponses);
     }
     return handleLoginNoElicitation(service, args, supportsMcpApps(capabilities));
 }
 /**
  * Handle `login_complete` — finish a login started by a prior `login` call
- * on a non-elicitation client. Awaits the same in-flight `runPwlessLogin`
- * promise `login` started, so the real success/failure surfaces here.
- * Never touches credentials on the failure path.
+ * on a client with no elicitation. Awaits the same in-flight
+ * `runPwlessLogin` promise `login` started, so the real success/failure
+ * surfaces here.
  *
  * @returns MCP tool result describing the logged-in profile, or an honest error.
  */
 export async function handleLoginComplete() {
-    if (!pendingLogin) {
+    const pending = getPendingLogin();
+    if (!pending) {
         return toolError('No login is pending. Call `login` first to start a passwordless login. ' +
             '(If you already called `login`, a previous attempt may have finished or its PIN code may have ' +
             `expired — LINE only gives the human about ${Math.round(LINE_PIN_CODE_LIFETIME_MS / 1000)} seconds ` +
             '(about 3 minutes) to act on a shown code. Calling `login` again is safe.)');
     }
-    const pending = pendingLogin;
     try {
-        const { mid, displayName } = await pending.promise;
-        pendingLogin = null;
-        log.info('login.complete', { mid });
+        const { mid, displayName } = await finishPendingLogin(pending);
         return {
             content: [
                 {
@@ -442,7 +296,6 @@ export async function handleLoginComplete() {
         };
     }
     catch (error) {
-        pendingLogin = null;
         return toolError(error?.message ?? String(error));
     }
 }

package/dist/mcp/server.js

@@ -12,7 +12,9 @@ import { LineProtocolService } from '../line/core/service.js';
 import { startCapture } from '../search/capture.js';
 import { getDefaultEmbedder } from '../search/default-embedder.js';
 import { createCliLogger } from '../util/log.js';
+import { checkForUpdate } from '../util/update-check.js';
 import { YOMI_VERSION } from '../version.js';
+import { clientCapabilitiesOf } from './client-capabilities.js';
 import { handleAcceptInvitation, handleAddFriend, handleBlockContact, handleCancelReaction, handleCollectMessages, handleCreateGroup, handleExcludeChats, handleFindContact, handleGetChatMessages, handleGetGroupMembers, handleGetInsight, handleGetMessageImage, handleGetMessageMedia, handleGetScopePolicy, handleGetUnreadDigest, handleIncludeChats, handleInviteMember, handleKickMember, handleLeaveGroup, handleListContacts, handleListConversations, handleListExcludedChats, handleListStickers, handleLogin, handleLoginComplete, handleMarkRead, handlePreviewSticker, handleReactMessage, handleRenameGroup, handleSearchMessages, handleSearchStickers, handleSendAudio, handleSendContact, handleSendFile, handleSendImage, handleSendLocation, handleSendMessage, handleSendSticker, handleSendVideo, handleUnblockContact, handleUnsendMessage, NO_CREDENTIALS_MESSAGE, sessionExpiredError, sessionRequiredError, sessionRevokedError, toolError, } from './handlers/index.js';
 import { getPrivacyPolicyText } from './policy.js';
 import { TOOLS } from './tools.js';
@@ -42,12 +44,21 @@ async function main() {
             });
         });
     }
+    // Asked once per process, bounded, best-effort: a hand-installed .mcpb
+    // bundle never auto-updates, so this notice is the only way a GUI-only user
+    // learns a newer Yomi exists (see ../util/update-check.ts). Awaited here
+    // because `instructions` is built once, before any client connects.
+    const updateNotice = await checkForUpdate();
+    if (updateNotice) {
+        log.info('update.available', { current: YOMI_VERSION });
+    }
     // `instructions` is surfaced by the MCP SDK to the client/model on
     // initialize — a "TOS on connect" privacy disclosure. It is a consent
     // notice, not decoration. A short model directive precedes the canonical
     // policy prose, which lives ONLY in PRIVACY.md (see ./policy.ts) so the
     // disclosure is single-sourced and never drifts from get_scope_policy.
-    const instructions = 'SESSION ERRORS — if a tool fails with a login-required or signed-out ' +
+    const instructions = (updateNotice ? `${updateNotice}\n\n` : '') +
+        'SESSION ERRORS — if a tool fails with a login-required or signed-out ' +
         'error, the MCP server and its connection are healthy: LINE revoked this ' +
         "device's session (usually because the same account logged in somewhere " +
         'else). Tell the user that plainly and offer the `login` tool. Never ' +
@@ -101,7 +112,7 @@ async function main() {
         server.setRequestHandler('tools/list', async () => {
             return { tools: toolsForClient(TOOLS, true) };
         });
-        server.setRequestHandler('tools/call', async (request) => {
+        server.setRequestHandler('tools/call', async (request, ctx) => {
             const { name, arguments: args } = request.params;
             // `login` is the one tool allowed without an existing session — it is
             // how a session gets created. `search_messages` also runs without a
@@ -136,7 +147,15 @@ async function main() {
             try {
                 switch (name) {
                     case 'login':
-                        return await handleLogin(server, service, (args ?? {}), server.getClientCapabilities(), era === 'legacy');
+                        // `era` selects HOW the login talks to the human: the legacy era
+                        // can push `elicitation/create`, the modern one answers with
+                        // multi-round-trip `input_required` results the client fulfils
+                        // and retries (`ctx.mcpReq.inputResponses` carries the answers).
+                        return await handleLogin(server, service, (args ?? {}), {
+                            era,
+                            capabilities: clientCapabilitiesOf(server, ctx),
+                            inputResponses: ctx.mcpReq.inputResponses,
+                        });
                     case 'login_complete':
                         return await handleLoginComplete();
                     case 'list_conversations':

package/dist/mcp/tools.js

@@ -1,6 +1,7 @@
+import { PRIMARY_DEVICE_SETTING_PATH } from './handlers/login-copy.js';
 export const TOOLS = [
     {
-        description: 'Log in to LINE via the passwordless secondary-device flow. Requires 允許自其他裝置登入 enabled on the primary phone. On MCP clients with elicitation, this call prompts for phone/region and PIN and completes login by itself. On clients without it (e.g. Claude Desktop), phone/region come from the arguments or a persisted login, and this returns as soon as LINE issues the PIN (or reports none needed) — then call login_complete IMMEDIATELY (do not wait for the human). LINE gives ~3 minutes from PIN display to confirm on the phone; login_complete blocks past that, so calling it late only wastes that window.',
+        description: `Log in to LINE via the passwordless secondary-device flow. Requires ${PRIMARY_DEVICE_SETTING_PATH} enabled on the primary phone — with it off LINE never prompts that phone and NO login can succeed, so raise this with the human up front rather than after a failure. On MCP clients with form elicitation, this call first confirms that setting, then prompts for phone/region and PIN and completes login by itself; if the human says the setting is off, it returns the enabling steps without starting a login (relay them verbatim, then call \`login\` again). On clients without it (e.g. Claude Desktop), phone/region come from the arguments or a persisted login, and this returns as soon as LINE issues the PIN (or reports none needed) — then call login_complete IMMEDIATELY (do not wait for the human). LINE gives ~3 minutes from PIN display to confirm on the phone; login_complete blocks past that, so calling it late only wastes that window.`,
         inputSchema: {
             type: 'object',
             properties: {
@@ -17,7 +18,7 @@ export const TOOLS = [
         name: 'login',
     },
     {
-        description: "Finish a passwordless login that `login` started on a client without elicitation (not needed on elicitation-capable clients). No arguments. Call immediately after `login` returns — do not wait for the human. Blocks while they enter the PIN (skipped if a stored certificate is valid) and approve the device, then returns the profile. LINE's real deadline is ~3 minutes from PIN display. Errors if no login is pending.",
+        description: "Finish a passwordless login that `login` started on a client without form elicitation (not needed on form-elicitation-capable clients). No arguments. Call immediately after `login` returns — do not wait for the human. Blocks while they enter the PIN (skipped if a stored certificate is valid) and approve the device, then returns the profile. LINE's real deadline is ~3 minutes from PIN display. Errors if no login is pending.",
         inputSchema: {
             type: 'object',
             properties: {},

package/dist/util/update-check.js

@@ -0,0 +1,121 @@
+/**
+ * "Is this copy of Yomi out of date?" — asked once at startup, answered to
+ * the model through the MCP `instructions` so it can tell the human.
+ *
+ * Why this exists: the drag-and-drop `.mcpb` bundle has NO auto-update. The
+ * MCPB manifest spec defines no update URL or endpoint (its `version` is
+ * plain metadata), and Claude Desktop only auto-updates extensions installed
+ * from the official directory — "for privately distributed extensions, users
+ * will need to install updated .mcpb files manually". Yomi's bundles are
+ * attached to GitHub Releases, so without this a user can sit on an old
+ * build indefinitely without ever knowing.
+ *
+ * It cannot self-update: a bundle carries native binaries (onnxruntime-node,
+ * sharp) and overwriting itself while running is neither safe nor portable.
+ * Telling the human, with the right link for how they installed, is the whole
+ * scope.
+ *
+ * PRIVACY. This is the ONE outbound request Yomi makes that is not to LINE,
+ * and it is disclosed in PRIVACY.md. It sends no message content and no
+ * account identifier — it is a plain GET of a public npm registry document.
+ * What it does reveal to the registry is that some IP is running Yomi, and
+ * (by what it does with the answer) roughly which version. `YOMI_NO_UPDATE_CHECK=1`
+ * turns it off completely.
+ */
+import { YOMI_VERSION } from '../version.js';
+/**
+ * The registry document for the published package. Queried directly rather
+ * than through `npm view`, which reads a CDN-cached view that lags behind a
+ * publish by minutes.
+ */
+const LATEST_URL = 'https://registry.npmjs.org/@rikaidev/yomi/latest';
+/** How long the check may take before startup gives up on it. */
+const TIMEOUT_MS = 1500;
+/**
+ * Compare two semver core versions (`major.minor.patch`).
+ *
+ * Pre-release suffixes are ignored on BOTH sides, which is deliberate: the
+ * only question here is "is a newer release available", and a local
+ * pre-release of the same core version should not nag.
+ *
+ * @param a - Left version.
+ * @param b - Right version.
+ * @returns Positive when `a` is newer, negative when older, 0 when equal.
+ */
+export function compareVersions(a, b) {
+    const parse = (value) => value
+        .trim()
+        .replace(/^v/, '')
+        .split('-')[0]
+        .split('.')
+        .map((part) => Number.parseInt(part, 10) || 0);
+    const left = parse(a);
+    const right = parse(b);
+    for (let i = 0; i < 3; i++) {
+        const diff = (left[i] ?? 0) - (right[i] ?? 0);
+        if (diff !== 0) {
+            return diff;
+        }
+    }
+    return 0;
+}
+/**
+ * How this copy of Yomi was installed, which decides what "update" means.
+ * The `.mcpb` build stamps `YOMI_DISTRIBUTION=mcpb` into the manifest's
+ * server env (scripts/build-mcpb.mjs); anything else is an npm/npx install.
+ *
+ * @returns The distribution channel.
+ */
+function distribution() {
+    return process.env.YOMI_DISTRIBUTION === 'mcpb' ? 'mcpb' : 'npm';
+}
+/**
+ * Build the notice handed to the model when a newer version exists.
+ *
+ * @param latest - The newest published version.
+ * @returns Notice text, phrased for how this copy was installed.
+ */
+export function updateNotice(latest) {
+    const how = distribution() === 'mcpb'
+        ? 'Desktop Extension bundles do NOT auto-update when installed by hand: the human has to ' +
+            'download the new .mcpb for their platform from ' +
+            'https://github.com/RikaiDev/yomi/releases/latest and drag it into Claude Desktop again ' +
+            '(same extension, it replaces this one).'
+        : 'Update with `npx @rikaidev/yomi@latest` (or reinstall the package) to pick it up.';
+    return (`UPDATE AVAILABLE — this Yomi is ${YOMI_VERSION}; ${latest} has been published. ` +
+        `${how} Mention this ONCE, early, in your own words, then carry on with what the user ` +
+        'asked — it is not urgent and never a reason to refuse work.');
+}
+/**
+ * Ask the registry whether a newer Yomi has been published.
+ *
+ * Best-effort by construction: offline, slow, rate-limited, or malformed
+ * answers all resolve to `null`. A version check must never delay or fail a
+ * server that is otherwise ready to work.
+ *
+ * @returns The notice text when an update exists, otherwise null.
+ */
+export async function checkForUpdate() {
+    if (process.env.YOMI_NO_UPDATE_CHECK === '1') {
+        return null;
+    }
+    try {
+        const response = await fetch(LATEST_URL, {
+            signal: AbortSignal.timeout(TIMEOUT_MS),
+            headers: { accept: 'application/json' },
+        });
+        if (!response.ok) {
+            return null;
+        }
+        const body = (await response.json());
+        const latest = typeof body.version === 'string' ? body.version : null;
+        if (!latest || compareVersions(latest, YOMI_VERSION) <= 0) {
+            return null;
+        }
+        return updateNotice(latest);
+    }
+    catch {
+        // Offline is the normal case here, not an error worth surfacing.
+        return null;
+    }
+}

package/dist/version.js

@@ -4,4 +4,4 @@
  * virtual filesystem). MUST stay equal to the "version" field in
  * package.json — the test in version.test.ts enforces that.
  */
-export const YOMI_VERSION = '0.4.0';
+export const YOMI_VERSION = '0.4.1';

package/package.json

@@ -3,7 +3,7 @@
   "engines": {
     "node": ">=22.13.0 <23.0.0 || >=23.4.0"
   },
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Open-source personal LINE MCP server for AI agents. Read, reply, send images, and search LINE conversations locally with Letter-Sealing E2EE.",
   "type": "module",
   "license": "MIT",