@enrichlayer/el-linear 1.41.1 → 1.43.0

package/README.md

@@ -489,6 +489,22 @@ el-linear <command> --help       # detailed help for one command
 All `list` subcommands support `-l, --limit <n>`. All commands accept the
 top-level filters: `--format <json|summary>`, `--raw`, `--jq <expr>`, `--fields <list>`.
 
+`issues list` also accepts `--all` (equivalent to `--limit 0`) to fetch **every**
+matching issue. It paginates the full set in safe chunks under the hood, so
+enumerating a large team no longer trips Linear's GraphQL complexity ceiling
+(`Query too complex`) the way a single big `--limit` used to — no manual
+per-status / per-priority bucketing needed:
+
+```bash
+el-linear issues list --team DEV --all --format csv --fields identifier   # the whole open DEV backlog, one command
+```
+
+`issues search` intentionally has no `--all`: Linear's full-text search is a
+relevance-ranked candidate search whose results are filtered client-side, not
+an exhaustive enumeration. Its `--limit` reads at most 200 ranked candidates to
+keep the rich issue query below Linear's complexity ceiling. Use `issues list`
+with structured filters and `--all` when you need every matching issue.
+
 ### Open by default — `issues list` and `issues search` skip terminal states
 
 `el-linear issues list` and `el-linear issues search` **exclude issues in

package/dist/commands/issues/description.js

@@ -20,6 +20,7 @@ import { loadConfig } from "../../config/config.js";
 import { UPDATE_ISSUE_MUTATION } from "../../queries/issues.js";
 import { autoLinkReferences, } from "../../utils/auto-link-references.js";
 import { normalizeInlineTextInput } from "../../utils/inline-text-input.js";
+import { assertNotIssueEnvelope } from "../../utils/issue-envelope-guard.js";
 import { extractIssueReferences } from "../../utils/issue-reference-extractor.js";
 import { wrapIssueReferencesAsLinks } from "../../utils/issue-reference-wrapper.js";
 import { readTextInputFile } from "../../utils/text-input-file.js";
@@ -53,11 +54,19 @@ export function resolveDescription(options) {
         throw new Error("--template is mutually exclusive with --description / --description-file. " +
             "Pick one.");
     }
+    // Guard both user-supplied paths (file + inline) against being handed an
+    // issue's own JSON envelope, which would silently overwrite the real body
+    // (DEV-6315). Template bodies are config-authored, so they're not checked.
+    const allow = options.allowJsonDescription === true;
     if (hasFile) {
-        return readDescriptionFile(options.descriptionFile);
+        const body = readDescriptionFile(options.descriptionFile);
+        assertNotIssueEnvelope(body, { allow });
+        return body;
     }
     if (hasInline) {
-        return normalizeInlineTextInput(options.description);
+        const body = normalizeInlineTextInput(options.description);
+        assertNotIssueEnvelope(body, { allow });
+        return body;
     }
     if (hasTemplate) {
         const templates = loadConfig().descriptionTemplates ?? {};

package/dist/commands/issues.js

@@ -16,6 +16,7 @@ import { emitGateEvent } from "../utils/gate-telemetry.js";
 import { createGraphQLAttachmentsService } from "../utils/graphql-attachments-service.js";
 import { createGraphQLService, } from "../utils/graphql-service.js";
 import { normalizeInlineTextInput } from "../utils/inline-text-input.js";
+import { assertNotIssueEnvelope } from "../utils/issue-envelope-guard.js";
 import { createIssuesService } from "../utils/issues-service-bootstrap.js";
 import { createLinearService, } from "../utils/linear-service.js";
 import { logger } from "../utils/logger.js";
@@ -217,7 +218,11 @@ async function handleListIssues(options, command) {
         options.project ||
         options.project === false ||
         options.priority;
-    const limit = parsePositiveInt(options.limit, "--limit");
+    // DEV-6312: `--all` / `--limit 0` mean unlimited. Stored as `limit = 0`,
+    // which the service's chunked pagination interprets as "fetch the whole
+    // matching set in safe pages" — mirrors `projects list --all` (DEV-4175).
+    const unlimited = options.all === true || options.limit === "0";
+    const limit = unlimited ? 0 : parsePositiveInt(options.limit, "--limit");
     // Route through searchIssues whenever the CLI needs to control the GraphQL
     // state filter: any explicit filter, the default `excludeTerminalStates`,
     // OR an explicit `--include-closed`. The last case is load-bearing —
@@ -1100,6 +1105,18 @@ async function handleUpdateIssue(issueId, options, command) {
     if (typeof options.appendDescription === "string") {
         options.appendDescription = normalizeInlineTextInput(options.appendDescription);
     }
+    // Guard against overwriting this issue's body with its own JSON envelope
+    // (DEV-6315). The update path resolves description inline rather than via
+    // resolveDescription(), so the guard is applied here too; --description,
+    // --description-file (normalized above), and --append-description are all
+    // checked (append would corrupt just as badly).
+    {
+        const allow = options.allowJsonDescription === true;
+        assertNotIssueEnvelope(typeof options.description === "string" ? options.description : undefined, { allow, targetIssueRef: issueId });
+        assertNotIssueEnvelope(typeof options.appendDescription === "string"
+            ? options.appendDescription
+            : undefined, { allow, targetIssueRef: issueId });
+    }
     validateUpdateOptions(options);
     const rootOpts = getRootOpts(command);
     const { graphQLService, linearService, issuesService } = await createIssuesService(rootOpts);
@@ -1381,6 +1398,7 @@ export function setupIssuesCommands(program) {
         .command("list")
         .description("List issues.")
         .option("-l, --limit <number>", "limit results", "25")
+        .option("--all", "fetch every matching issue (paginates fully in safe chunks). Equivalent to --limit 0; overrides --limit when both are given.")
         .option("--search <query>", "full-text search term; composes with list filters")
         .option("--team <team>", "filter by team key (EL: resolves names)")
         .option("--assignee <assignee>", "filter by assignee (name, alias, or ID)")
@@ -1412,7 +1430,7 @@ export function setupIssuesCommands(program) {
         .option("--sort <field>", "sort results (priority, status, created, updated)")
         .option("--format <format>", "output format (json, summary, table, md, csv)", "json")
         .option("--fields <fields>", "columns for table/csv output")
-        .option("-l, --limit <number>", "limit results", "10")
+        .option("-l, --limit <number>", "limit results (full-text search reads at most 200 ranked candidates)", "10")
         .action(handleAsyncCommand(handleSearchIssues));
     issues
         .command("create [title]")
@@ -1421,6 +1439,7 @@ export function setupIssuesCommands(program) {
         .option("-d, --description <desc>", "issue description")
         .option("--description-file <path>", "read description from file (use - for stdin)")
         .option("--template <name>", "use a named description template from config.descriptionTemplates")
+        .option("--allow-json-description", "allow a --description / --description-file body that looks like an issue's JSON envelope (normally blocked to prevent silently overwriting a body with 'issues get --format json' output — DEV-6315)")
         .option("--from-template <id>", "instantiate the issue from a Linear server-side template (UUID from `el-linear templates list`). Sets templateId on the underlying issueCreate mutation; Linear copies the template's title, description, labels, priority, etc. as the new issue's defaults. Override any field with the matching --title / --description / --labels flag.")
         .option("-a, --assignee <assignee>", "assign to user (name, alias, or UUID)")
         .option("--delegate <delegate>", "delegate implementation to an agent app user (name, alias, or UUID)")
@@ -1503,6 +1522,7 @@ export function setupIssuesCommands(program) {
         .option("-t, --title <title>", "new title")
         .option("-d, --description <desc>", "new description")
         .option("--description-file <path>", "read description from file (use - for stdin)")
+        .option("--allow-json-description", "allow a --description / --description-file body that looks like an issue's JSON envelope (normally blocked to prevent silently overwriting a body with 'issues get --format json' output — DEV-6315)")
         .option("--append-description <text>", "append text to the existing description")
         .option("-s, --status <status>", "new status name or ID")
         .option("--state <status>", "alias for --status (new status name or ID)")

package/dist/config/config.d.ts

@@ -36,6 +36,31 @@ export interface ElLinearConfig {
     };
     teamAliases: Record<string, string>;
     teams: Record<string, string>;
+    /**
+     * Optional identity-resolver hook (DEV-5628). `resolver` is an argv array —
+     * el-linear appends the identifier as the final element and reads a Linear
+     * user UUID off stdout:
+     *
+     *   "identity": { "resolver": ["el-identity", "resolve"] }
+     *
+     * Use it when your org has a people registry that knows things Linear does
+     * not (that `jd` is a person; that a GitLab handle and a Linear handle are one human).
+     *
+     * It is a COMMAND rather than a URL + credentials on purpose: el-linear is
+     * MIT and most installs are not ours, so it must not bake in anybody's auth
+     * scheme. The credential lives entirely inside whatever you point this at —
+     * Vault, Infisical, 1Password, a plain env var, SSO. Adding a backend is
+     * writing a different script, not patching this package.
+     *
+     * Entirely optional and fail-open: unconfigured, or on any failure,
+     * resolution falls through to Linear's own user lookup exactly as before.
+     * See `identity-resolver.ts` for the output contract.
+     */
+    identity?: {
+        resolver?: string[];
+        /** Milliseconds before the resolver is treated as a miss (default 8000). */
+        resolverTimeoutMs?: number;
+    };
     /**
      * Term-enforcement rules. Each rule has a canonical form and a list of
      * rejected forms; rejected forms in issue titles/descriptions are flagged

package/dist/config/config.js

@@ -139,6 +139,21 @@ export function loadConfig() {
         : {};
     // teamConfigPath inside a team config file would be circular; strip it.
     delete teamRaw.teamConfigPath;
+    // `identity.resolver` names a BINARY el-linear will spawn. The team layer is
+    // data, not code: it arrives from a different repository via `git pull` (or,
+    // for an OSS user, from whatever repo they pointed `teamConfigPath` at), and
+    // nobody reviews a config file expecting it to hand them a subprocess. Letting
+    // it choose the executable would turn "clone this repo and run el-linear" into
+    // arbitrary code execution on every `--assignee` resolution.
+    //
+    // So the resolver is honored ONLY from the personal config (or the env var) —
+    // files the operator owns. Same reasoning as teamConfigPath above, which is
+    // stripped for the same "the team layer doesn't get to decide this" reason.
+    //
+    // An organization that wants to ship a resolver to its developers writes it
+    // into their personal config at setup time; that keeps the decision with the
+    // machine's owner instead of with whoever can land a commit upstream.
+    delete teamRaw.identity;
     // Merge order: defaults → team config → personal config.
     // Arrays (terms, defaultLabels, etc.) are concatenated so personal entries
     // extend team entries rather than replace them.

package/dist/config/identity-resolver.d.ts

@@ -0,0 +1,40 @@
+import type { ElLinearConfig } from "./config.js";
+/** Test seam — the memo would otherwise leak between cases in one vitest process. */
+export declare function clearResolverMemoForTests(): void;
+/**
+ * The configured resolver argv, or `null` when the hook is off.
+ *
+ * Env wins over config so a single invocation can point at a different resolver
+ * (or disable one) without editing files: `EL_LINEAR_IDENTITY_RESOLVER=""` is an
+ * explicit off switch.
+ */
+export declare function resolverCommand(config: Pick<ElLinearConfig, "identity">, env?: NodeJS.ProcessEnv): string[] | null;
+/** True when an identity resolver is configured (env or config). */
+export declare function isResolverConfigured(config: Pick<ElLinearConfig, "identity">, env?: NodeJS.ProcessEnv): boolean;
+/**
+ * Pull a Linear user UUID out of whatever the resolver printed.
+ *
+ * Deliberately generous about the shape, because the point of this hook is that
+ * anyone can write the resolver — demanding one exact JSON envelope would make
+ * the "just shell out to your own script" promise a lie. Accepted:
+ *
+ *   - a bare UUID:                     `3f2a…`
+ *   - `{"linearId": "3f2a…"}`     (the el-identity record shape)
+ *   - `{"data": {"linearId": "…"}}`    (an el-* CLI `{data, meta}` envelope)
+ *   - `{"id": "3f2a…"}`           (the obvious alternative spelling)
+ *
+ * Anything else — including a *non*-UUID string, which is the shape a confused
+ * resolver most plausibly emits — is a miss. We would rather fall through to
+ * Linear's own lookup than hand a bogus id to the API and produce an opaque
+ * "Argument Validation Error" (the DEV-4312 failure, in a new costume).
+ */
+export declare function parseResolverOutput(stdout: string): string | null;
+/**
+ * Run the configured resolver for `identifier`. Returns the Linear user UUID, or
+ * `null` on any miss/failure. Never throws.
+ *
+ * Synchronous (`spawnSync`) on purpose: resolution sits on the critical path of
+ * `--assignee` for a short-lived CLI, the callers are already `async` so nothing
+ * is starved, and it keeps the failure modes to exactly one place.
+ */
+export declare function resolveViaCommand(identifier: string, config: Pick<ElLinearConfig, "identity">, env?: NodeJS.ProcessEnv): string | null;

package/dist/config/identity-resolver.js

@@ -0,0 +1,253 @@
+import { spawnSync } from "node:child_process";
+/**
+ * Optional **identity resolver hook** (DEV-5628).
+ *
+ * Some organizations keep a people registry that knows things Linear does not:
+ * that `jd` is a person, that a GitLab handle and a Linear handle belong to the
+ * same human. el-linear can consult it — but it must never learn *how* to reach it.
+ *
+ * So the hook is a **command**, not an HTTP client:
+ *
+ *   identity.resolver = ["el-identity", "resolve"]
+ *
+ * el-linear appends the identifier as the final argv element, runs the command,
+ * and reads a Linear user UUID off stdout. That is the entire contract.
+ *
+ * Why a command rather than a URL + credentials (which is what
+ * `registry-resolve.ts` does, and why that path stayed dormant): el-linear is
+ * MIT and published on npm. Most installs are not Enrich Layer. Baking in an
+ * auth scheme means baking in *somebody's* auth scheme — and the moment we did,
+ * the next organization would need Infisical, or 1Password, or a plain env var,
+ * or SSO. A command has no such problem: the credential lives entirely inside
+ * whatever the operator points this at. Adding a new secret backend is writing a
+ * different script, not patching this package.
+ *
+ * The command is trusted (the operator configured it) but the *identifier* is
+ * not, so it is passed as an argv element with `shell: false` — a name like
+ * `"; rm -rf /"` is an argument, never a command.
+ *
+ * Fail-open by design: unconfigured, a miss, a non-zero exit, a timeout, an
+ * unparseable answer, or a missing binary all return `null`, and the caller
+ * falls through to Linear's own user lookup (which resolves names and emails
+ * perfectly well — see `LinearService.resolveUserId`). This hook is an
+ * *enhancement*, so a broken resolver must degrade to plain el-linear rather
+ * than break every command. It never throws.
+ */
+/** Env override — a whitespace-separated command, e.g. `el-identity resolve`. */
+const RESOLVER_ENV = "EL_LINEAR_IDENTITY_RESOLVER";
+/** A resolver that hasn't answered in this long is not going to. */
+const DEFAULT_TIMEOUT_MS = 8000;
+/**
+ * Per-process memo. A single command can resolve the same person several times —
+ * `--subscriber a,b,a`, or an assignee who is also a subscriber — and each miss
+ * costs a full subprocess round-trip (seconds, against a network-backed
+ * resolver). Nothing here is cached across processes: el-linear is short-lived,
+ * and a stale identity cache on disk is exactly the drift this hook exists to
+ * remove.
+ */
+const memo = new Map();
+/** Test seam — the memo would otherwise leak between cases in one vitest process. */
+export function clearResolverMemoForTests() {
+    memo.clear();
+}
+/**
+ * Resolve the effective timeout.
+ *
+ * `?? DEFAULT` is not enough: Node treats `timeout <= 0` as *no timeout*, and `0`
+ * is the most natural thing to type when you mean "off". That would turn the
+ * documented fail-open contract into an unkillable hang inside a synchronous
+ * call — the one failure mode the surrounding try/catch cannot save you from.
+ */
+function resolveTimeoutMs(config) {
+    const configured = config.identity?.resolverTimeoutMs;
+    return typeof configured === "number" && configured > 0
+        ? configured
+        : DEFAULT_TIMEOUT_MS;
+}
+/**
+ * The environment handed to the resolver.
+ *
+ * It inherits the ambient env on purpose — reaching its own secret backend
+ * (Vault, Infisical, 1Password, a plain env var) is the entire point, so
+ * scrubbing wholesale would defeat the design. But the resolver has no business
+ * with *Linear's* token: it resolves people, it never talks to Linear. Dropping
+ * it keeps the CLI's most sensitive secret out of the blast radius of a
+ * compromised — or merely over-logging — resolver.
+ */
+function resolverEnv(env) {
+    const { LINEAR_API_TOKEN: _dropped, ...rest } = env;
+    return rest;
+}
+/**
+ * Debug-gated diagnosis. Every failure here is a silent `null` by design, which
+ * is right for the user but miserable for the operator whose resolver is broken:
+ * all they see is an unexplained pause. `EL_LINEAR_DEBUG=1` is this repo's
+ * existing convention for "tell me what actually happened", and stderr never
+ * corrupts the JSON on stdout.
+ */
+function debugMiss(reason, env) {
+    if (!env.EL_LINEAR_DEBUG)
+        return;
+    process.stderr.write(`el-linear: identity resolver miss — ${reason}\n`);
+}
+/**
+ * The configured resolver argv, or `null` when the hook is off.
+ *
+ * Env wins over config so a single invocation can point at a different resolver
+ * (or disable one) without editing files: `EL_LINEAR_IDENTITY_RESOLVER=""` is an
+ * explicit off switch.
+ */
+export function resolverCommand(config, env = process.env) {
+    const fromEnv = env[RESOLVER_ENV];
+    if (fromEnv !== undefined) {
+        const argv = fromEnv.trim().split(/\s+/).filter(Boolean);
+        return argv.length > 0 ? argv : null;
+    }
+    const configured = config.identity?.resolver;
+    if (!configured || configured.length === 0) {
+        return null;
+    }
+    return configured;
+}
+/** True when an identity resolver is configured (env or config). */
+export function isResolverConfigured(config, env = process.env) {
+    return resolverCommand(config, env) !== null;
+}
+/**
+ * Pull a Linear user UUID out of whatever the resolver printed.
+ *
+ * Deliberately generous about the shape, because the point of this hook is that
+ * anyone can write the resolver — demanding one exact JSON envelope would make
+ * the "just shell out to your own script" promise a lie. Accepted:
+ *
+ *   - a bare UUID:                     `3f2a…`
+ *   - `{"linearId": "3f2a…"}`     (the el-identity record shape)
+ *   - `{"data": {"linearId": "…"}}`    (an el-* CLI `{data, meta}` envelope)
+ *   - `{"id": "3f2a…"}`           (the obvious alternative spelling)
+ *
+ * Anything else — including a *non*-UUID string, which is the shape a confused
+ * resolver most plausibly emits — is a miss. We would rather fall through to
+ * Linear's own lookup than hand a bogus id to the API and produce an opaque
+ * "Argument Validation Error" (the DEV-4312 failure, in a new costume).
+ */
+export function parseResolverOutput(stdout) {
+    const trimmed = stdout.trim();
+    if (!trimmed) {
+        return null;
+    }
+    if (UUID_RE.test(trimmed)) {
+        return trimmed;
+    }
+    let parsed;
+    try {
+        parsed = JSON.parse(trimmed);
+    }
+    catch {
+        return null;
+    }
+    const candidate = pickLinearId(parsed);
+    return candidate && UUID_RE.test(candidate) ? candidate : null;
+}
+const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
+function pickLinearId(parsed) {
+    if (typeof parsed === "string") {
+        return parsed;
+    }
+    if (!parsed || typeof parsed !== "object") {
+        return null;
+    }
+    const obj = parsed;
+    for (const key of ["linearId", "id"]) {
+        const value = obj[key];
+        if (typeof value === "string") {
+            return value;
+        }
+    }
+    // One level of `{data: …}` unwrapping — the el-* CLI envelope.
+    if (obj.data && typeof obj.data === "object") {
+        return pickLinearId(obj.data);
+    }
+    return null;
+}
+/**
+ * Run the configured resolver for `identifier`. Returns the Linear user UUID, or
+ * `null` on any miss/failure. Never throws.
+ *
+ * Synchronous (`spawnSync`) on purpose: resolution sits on the critical path of
+ * `--assignee` for a short-lived CLI, the callers are already `async` so nothing
+ * is starved, and it keeps the failure modes to exactly one place.
+ */
+export function resolveViaCommand(identifier, config, env = process.env) {
+    const argv = resolverCommand(config, env);
+    if (!argv) {
+        return null;
+    }
+    const [command, ...args] = argv;
+    if (!command) {
+        return null;
+    }
+    // A leading `-` is never a valid Linear identifier, but it IS a flag to the
+    // resolver's own option parser — `--assignee "--output=/tmp/x"` would be
+    // presented to it as one. There is no shell escape here (argv, not a shell),
+    // but el-linear is increasingly driven by agents over untrusted issue text, so
+    // close the class for free rather than trust every resolver to be careful.
+    if (identifier.startsWith("-")) {
+        debugMiss(`refusing flag-shaped identifier "${identifier}"`, env);
+        return null;
+    }
+    const cached = memo.get(identifier);
+    if (cached !== undefined) {
+        return cached;
+    }
+    const resolved = spawnResolver(command, args, identifier, config, env);
+    memo.set(identifier, resolved);
+    return resolved;
+}
+function spawnResolver(command, args, identifier, config, env) {
+    try {
+        const result = spawnSync(command, [...args, identifier], {
+            encoding: "utf8",
+            timeout: resolveTimeoutMs(config),
+            // `spawnSync` waits for the child to fully exit after its timeout. Its
+            // default kill signal is SIGTERM, which a broken resolver can trap or
+            // ignore forever — defeating this hook's fail-open timeout. The resolver
+            // is an isolated lookup helper, so force it down when its time budget is
+            // exhausted rather than letting it wedge the whole CLI.
+            killSignal: "SIGKILL",
+            // The identifier is untrusted input; never hand it to a shell. This also
+            // means a Windows npm shim (`el-identity.cmd`) will NOT be found — see
+            // the Windows note in docs/configuration.md. Turning `shell: true` on to
+            // fix that would hand the untrusted identifier to cmd.exe, which is a
+            // far worse trade.
+            shell: false,
+            // stdin closed: a resolver that decides to prompt must not hang the CLI.
+            stdio: ["ignore", "pipe", "pipe"],
+            env: resolverEnv(env),
+        });
+        // BOTH conditions are load-bearing; do not "simplify" this to one.
+        //   - a plain timeout      → error ETIMEDOUT, status null
+        //   - a maxBuffer overflow → error ENOBUFS,   status null
+        //   - a child that leaves a grandchild holding the stdout pipe
+        //                          → error ETIMEDOUT, status **0**
+        // Checking only `status` would let that last case through as a success and
+        // parse whatever partial output happened to be buffered.
+        if (result.error) {
+            debugMiss(`${command}: ${result.error.message}`, env);
+            return null;
+        }
+        if (result.status !== 0) {
+            const stderr = (result.stderr ?? "").trim().split("\n")[0] ?? "";
+            debugMiss(`${command} exited ${result.status}${stderr ? `: ${stderr}` : ""}`, env);
+            return null;
+        }
+        const parsed = parseResolverOutput(result.stdout ?? "");
+        if (!parsed) {
+            debugMiss(`${command} printed no usable Linear UUID for "${identifier}"`, env);
+        }
+        return parsed;
+    }
+    catch (err) {
+        debugMiss(err instanceof Error ? err.message : String(err), env);
+        return null;
+    }
+}

package/dist/config/resolver.d.ts

@@ -14,14 +14,29 @@ export declare function resolveMember(input: string): string;
  */
 export declare function resolveAssignee(input: string, rootOpts: Record<string, unknown>): Promise<string>;
 /**
- * Resolve a member identifier (alias / handle / name) to a UUID, consulting the
- * opt-in identity registry first when configured, then the bundled config
- * (`resolveMember`). The shared async resolution path behind `--assignee` and
- * `--delegate` (DEV-4871 / DEV-4872).
+ * Resolve a member identifier (alias / handle / name) to a UUID. The shared
+ * async resolution path behind `--assignee` and `--delegate` (DEV-4871 /
+ * DEV-4872 / DEV-5628).
  *
- * EL-only and env-gated on `EL_IDENTITY_URL`; fail-open — when unconfigured, on
- * a miss, or on any failure it falls back to config, so a non-EL install and an
- * unreachable registry both behave exactly as before. Never throws.
+ * Order, most authoritative first:
+ *
+ *   1. **The identity-resolver hook** (`identity.resolver`, DEV-5628) — an
+ *      operator-supplied command. This is the one to reach for: it can answer
+ *      for aliases and cross-system handles Linear has never heard of, and it
+ *      owns its own credentials, so el-linear carries no auth scheme.
+ *   2. **The HTTP registry** (`EL_IDENTITY_URL`, DEV-4871) — the older,
+ *      env-gated path. Superseded by (1), which needs no URL or CF-Access
+ *      credentials in the environment. Kept because it ships and someone may
+ *      rely on it.
+ *   3. **The bundled config** (`resolveMember`) — a local lookup table.
+ *
+ * All three are optional. With none of them, `resolveMember` hands the raw input
+ * back and Linear's own user lookup resolves it (`LinearService.resolveUserId`
+ * matches email → displayName → name), which is why an install with no config at
+ * all still works.
+ *
+ * Fail-open throughout: a miss or a failure at any layer falls through to the
+ * next. Never throws.
  */
 export declare function resolveMemberWithRegistry(input: string): Promise<string>;
 /**

package/dist/config/resolver.js

@@ -2,6 +2,7 @@ import { createGraphQLService } from "../utils/graphql-service.js";
 import { outputWarning } from "../utils/output.js";
 import { isUuid, isUuidPrefix } from "../utils/uuid.js";
 import { loadConfig } from "./config.js";
+import { resolveViaCommand } from "./identity-resolver.js";
 import { isRegistryConfigured, resolveViaRegistry, } from "./registry-resolve.js";
 /**
  * Resolve a team key/name/alias to its UUID.
@@ -102,16 +103,39 @@ export async function resolveAssignee(input, rootOpts) {
     return resolveMemberWithRegistry(input);
 }
 /**
- * Resolve a member identifier (alias / handle / name) to a UUID, consulting the
- * opt-in identity registry first when configured, then the bundled config
- * (`resolveMember`). The shared async resolution path behind `--assignee` and
- * `--delegate` (DEV-4871 / DEV-4872).
+ * Resolve a member identifier (alias / handle / name) to a UUID. The shared
+ * async resolution path behind `--assignee` and `--delegate` (DEV-4871 /
+ * DEV-4872 / DEV-5628).
  *
- * EL-only and env-gated on `EL_IDENTITY_URL`; fail-open — when unconfigured, on
- * a miss, or on any failure it falls back to config, so a non-EL install and an
- * unreachable registry both behave exactly as before. Never throws.
+ * Order, most authoritative first:
+ *
+ *   1. **The identity-resolver hook** (`identity.resolver`, DEV-5628) — an
+ *      operator-supplied command. This is the one to reach for: it can answer
+ *      for aliases and cross-system handles Linear has never heard of, and it
+ *      owns its own credentials, so el-linear carries no auth scheme.
+ *   2. **The HTTP registry** (`EL_IDENTITY_URL`, DEV-4871) — the older,
+ *      env-gated path. Superseded by (1), which needs no URL or CF-Access
+ *      credentials in the environment. Kept because it ships and someone may
+ *      rely on it.
+ *   3. **The bundled config** (`resolveMember`) — a local lookup table.
+ *
+ * All three are optional. With none of them, `resolveMember` hands the raw input
+ * back and Linear's own user lookup resolves it (`LinearService.resolveUserId`
+ * matches email → displayName → name), which is why an install with no config at
+ * all still works.
+ *
+ * Fail-open throughout: a miss or a failure at any layer falls through to the
+ * next. Never throws.
  */
 export async function resolveMemberWithRegistry(input) {
+    // UUIDs are already canonical — don't spend a subprocess on them.
+    if (isUuid(input)) {
+        return input;
+    }
+    const viaCommand = resolveViaCommand(input, loadConfig());
+    if (viaCommand) {
+        return viaCommand;
+    }
     if (isRegistryConfigured()) {
         const viaRegistry = await resolveViaRegistry(input);
         if (viaRegistry) {

package/dist/queries/issues-types.d.ts

@@ -147,10 +147,20 @@ export interface BatchGetIssuesResponse {
         nodes: IssueWithCommentsNode[];
     };
 }
+/**
+ * Cursor-pagination page metadata (DEV-6312). Present on the connection
+ * responses the list/search enumeration paths chunk through so a large
+ * `--limit` / `--all` never blows Linear's GraphQL complexity ceiling.
+ */
+export interface IssuePageInfo {
+    hasNextPage: boolean;
+    endCursor: string | null;
+}
 /** Response shape for `GET_ISSUES_QUERY`. */
 export interface GetIssuesResponse {
     issues: {
         nodes: IssueNode[];
+        pageInfo?: IssuePageInfo;
     };
 }
 /**
@@ -161,6 +171,7 @@ export interface TeamScopedFilteredIssuesResponse {
     team: {
         issues: {
             nodes: IssueNode[];
+            pageInfo?: IssuePageInfo;
         };
     } | null;
 }

package/dist/queries/issues.d.ts

@@ -1,6 +1,6 @@
-export declare const GET_ISSUES_QUERY = "\n  query GetIssues($first: Int!, $orderBy: PaginationOrderBy) {\n    issues(\n      first: $first\n      orderBy: $orderBy\n      filter: {\n        state: { type: { neq: \"completed\" } }\n      }\n    ) {\n      nodes {\n        \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n      }\n    }\n  }\n";
+export declare const GET_ISSUES_QUERY = "\n  query GetIssues($first: Int!, $after: String, $orderBy: PaginationOrderBy) {\n    issues(\n      first: $first\n      after: $after\n      orderBy: $orderBy\n      filter: {\n        state: { type: { neq: \"completed\" } }\n      }\n    ) {\n      nodes {\n        \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n      }\n      pageInfo {\n        hasNextPage\n        endCursor\n      }\n    }\n  }\n";
 export declare const SEARCH_ISSUES_QUERY = "\n  query SearchIssues($term: String!, $first: Int!) {\n    searchIssues(term: $term, first: $first, includeArchived: false) {\n      nodes {\n        \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n      }\n    }\n  }\n";
-export declare const FILTERED_SEARCH_ISSUES_QUERY = "\n  query FilteredSearchIssues(\n    $first: Int!\n    $filter: IssueFilter\n    $orderBy: PaginationOrderBy\n  ) {\n    issues(\n      first: $first\n      filter: $filter\n      orderBy: $orderBy\n      includeArchived: false\n    ) {\n      nodes {\n        \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n      }\n    }\n  }\n";
+export declare const FILTERED_SEARCH_ISSUES_QUERY = "\n  query FilteredSearchIssues(\n    $first: Int!\n    $after: String\n    $filter: IssueFilter\n    $orderBy: PaginationOrderBy\n  ) {\n    issues(\n      first: $first\n      after: $after\n      filter: $filter\n      orderBy: $orderBy\n      includeArchived: false\n    ) {\n      nodes {\n        \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n      }\n      pageInfo {\n        hasNextPage\n        endCursor\n      }\n    }\n  }\n";
 /**
  * Team-scoped variant of `FILTERED_SEARCH_ISSUES_QUERY` (DEV-5578).
  *
@@ -19,7 +19,7 @@ export declare const FILTERED_SEARCH_ISSUES_QUERY = "\n  query FilteredSearchIss
  * (state / labels / assignee / priority / project) is applied on top of the
  * already-team-scoped connection.
  */
-export declare const TEAM_SCOPED_FILTERED_ISSUES_QUERY = "\n  query TeamScopedFilteredIssues(\n    $teamId: String!\n    $first: Int!\n    $filter: IssueFilter\n    $orderBy: PaginationOrderBy\n  ) {\n    team(id: $teamId) {\n      issues(\n        first: $first\n        filter: $filter\n        orderBy: $orderBy\n        includeArchived: false\n      ) {\n        nodes {\n          \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n        }\n      }\n    }\n  }\n";
+export declare const TEAM_SCOPED_FILTERED_ISSUES_QUERY = "\n  query TeamScopedFilteredIssues(\n    $teamId: String!\n    $first: Int!\n    $after: String\n    $filter: IssueFilter\n    $orderBy: PaginationOrderBy\n  ) {\n    team(id: $teamId) {\n      issues(\n        first: $first\n        after: $after\n        filter: $filter\n        orderBy: $orderBy\n        includeArchived: false\n      ) {\n        nodes {\n          \n  \n  id\n  identifier\n  title\n  description\n  summary { content generationStatus }\n  branchName\n  priority\n  estimate\n  dueDate\n  url\n  createdAt\n  updatedAt\n  completedAt\n\n  \n  state {\n    id\n    name\n    type\n  }\n\n  \n  assignee {\n    id\n    name\n    url\n  }\n\n  \n  delegate {\n    id\n    name\n    url\n  }\n\n  \n  team {\n    id\n    key\n    name\n  }\n\n  \n  project {\n    id\n    name\n  }\n\n  \n  labels {\n    nodes {\n      id\n      name\n    }\n  }\n\n  \n  cycle {\n    id\n    name\n    number\n  }\n\n  \n  projectMilestone {\n    id\n    name\n    targetDate\n  }\n\n  \n  parent {\n    id\n    identifier\n    title\n  }\n\n  \n  children {\n    nodes {\n      id\n      identifier\n      title\n    }\n  }\n\n\n        }\n        pageInfo {\n          hasNextPage\n          endCursor\n        }\n      }\n    }\n  }\n";
 /**
  * Batch-resolves a search's team/project/assignee/delegate filter inputs.
  *

package/dist/queries/issues.js

@@ -1,8 +1,9 @@
 import { COMPLETE_ISSUE_FRAGMENT, COMPLETE_ISSUE_WITH_COMMENTS_FRAGMENT, } from "./common.js";
 export const GET_ISSUES_QUERY = `
-  query GetIssues($first: Int!, $orderBy: PaginationOrderBy) {
+  query GetIssues($first: Int!, $after: String, $orderBy: PaginationOrderBy) {
     issues(
       first: $first
+      after: $after
       orderBy: $orderBy
       filter: {
         state: { type: { neq: "completed" } }
@@ -11,6 +12,10 @@ export const GET_ISSUES_QUERY = `
       nodes {
         ${COMPLETE_ISSUE_FRAGMENT}
       }
+      pageInfo {
+        hasNextPage
+        endCursor
+      }
     }
   }
 `;
@@ -26,11 +31,13 @@ export const SEARCH_ISSUES_QUERY = `
 export const FILTERED_SEARCH_ISSUES_QUERY = `
   query FilteredSearchIssues(
     $first: Int!
+    $after: String
     $filter: IssueFilter
     $orderBy: PaginationOrderBy
   ) {
     issues(
       first: $first
+      after: $after
       filter: $filter
       orderBy: $orderBy
       includeArchived: false
@@ -38,6 +45,10 @@ export const FILTERED_SEARCH_ISSUES_QUERY = `
       nodes {
         ${COMPLETE_ISSUE_FRAGMENT}
       }
+      pageInfo {
+        hasNextPage
+        endCursor
+      }
     }
   }
 `;
@@ -63,12 +74,14 @@ export const TEAM_SCOPED_FILTERED_ISSUES_QUERY = `
   query TeamScopedFilteredIssues(
     $teamId: String!
     $first: Int!
+    $after: String
     $filter: IssueFilter
     $orderBy: PaginationOrderBy
   ) {
     team(id: $teamId) {
       issues(
         first: $first
+        after: $after
         filter: $filter
         orderBy: $orderBy
         includeArchived: false
@@ -76,6 +89,10 @@ export const TEAM_SCOPED_FILTERED_ISSUES_QUERY = `
         nodes {
           ${COMPLETE_ISSUE_FRAGMENT}
         }
+        pageInfo {
+          hasNextPage
+          endCursor
+        }
       }
     }
   }

package/dist/utils/graphql-issues-service.d.ts

@@ -183,6 +183,21 @@ export declare class GraphQLIssuesService {
     private readonly graphQLService;
     private readonly linearService;
     constructor(graphQLService: GraphQLService, linearService: LinearService);
+    /**
+     * Chunked cursor pagination shared by every issue-enumeration path
+     * (DEV-6312). Fetches successive pages of at most `SAFE_ISSUE_PAGE_SIZE`
+     * via `fetchPage(first, after)` until the target is met or the connection
+     * is exhausted, so a large `--limit` (or `--all`, passed as `target === 0`)
+     * never issues one oversized request that Linear rejects as "Query too
+     * complex".
+     *
+     * `target === 0` means unlimited (fetch the whole connection). A positive
+     * target caps the total and trims any final-page overshoot. `fetchPage`
+     * returns `null` when the connection root is absent (e.g. an unresolved
+     * team) — treated as an empty result. A page that claims `hasNextPage` but
+     * returns zero nodes terminates the loop rather than spinning forever.
+     */
+    private paginateIssueNodes;
     getIssues(limit?: number): Promise<LinearIssue[]>;
     getIssueById(issueId: string): Promise<LinearIssue>;
     /**

package/dist/utils/graphql-issues-service.js

@@ -1,3 +1,5 @@
+import { loadConfig } from "../config/config.js";
+import { resolveViaCommand } from "../config/identity-resolver.js";
 import { isRegistryConfigured, resolveViaRegistry, } from "../config/registry-resolve.js";
 import { resolveUserDisplayName } from "../config/resolver.js";
 import { ARCHIVE_ISSUE_MUTATION, BATCH_GET_ISSUES_QUERY, BATCH_RESOLVE_FOR_CREATE_QUERY, BATCH_RESOLVE_FOR_SEARCH_QUERY, BATCH_RESOLVE_FOR_UPDATE_QUERY, buildResolveLabelsByNameQuery, CREATE_ISSUE_MUTATION, DELETE_ISSUE_MUTATION, FILTERED_SEARCH_ISSUES_QUERY, GET_ISSUE_BY_ID_QUERY, GET_ISSUE_BY_IDENTIFIER_QUERY, GET_ISSUE_CLAIM_CONTEXT_QUERY, GET_ISSUE_START_CONTEXT_QUERY, GET_ISSUE_TEAM_QUERY, GET_ISSUES_QUERY, SEARCH_ISSUES_QUERY, TEAM_SCOPED_FILTERED_ISSUES_QUERY, TEAM_STARTED_STATUSES_QUERY, UPDATE_ISSUE_MUTATION, } from "../queries/issues.js";
@@ -10,6 +12,18 @@ import { parseIssueIdentifier, tryParseIssueIdentifier, } from "./identifier-par
 import { logger } from "./logger.js";
 import { isUuid } from "./uuid.js";
 const TEAM_KEY_REGEX = /^[A-Z0-9]+$/i;
+/**
+ * Per-page cap for the chunked issue-enumeration paths (DEV-6312).
+ *
+ * The list/search queries embed the rich `COMPLETE_ISSUE_FRAGMENT`, so a single
+ * page's GraphQL complexity scales with `first`. Linear rejects any query above
+ * complexity 10000; empirically `first: 500` measured ~10900, i.e. ~21.8 per
+ * issue. 200 keeps a page near ~4400 — comfortably under the ceiling with
+ * headroom for the fragment growing — while still being few enough round-trips
+ * for large teams. A big `--limit` (or `--all`) is fetched as successive pages
+ * of this size rather than one oversized request that would be rejected.
+ */
+const SAFE_ISSUE_PAGE_SIZE = 200;
 function extractSummaryText(summary) {
     if (summary.generationStatus !== "completed" || !summary.content) {
         return undefined;
@@ -60,12 +74,55 @@ export class GraphQLIssuesService {
         this.graphQLService = graphQLService;
         this.linearService = linearService;
     }
-    async getIssues(limit = 25) {
-        const result = await this.graphQLService.rawRequest(GET_ISSUES_QUERY, { first: limit, orderBy: "updatedAt" });
-        const nodes = result.issues?.nodes;
-        if (!nodes?.length) {
-            return [];
+    /**
+     * Chunked cursor pagination shared by every issue-enumeration path
+     * (DEV-6312). Fetches successive pages of at most `SAFE_ISSUE_PAGE_SIZE`
+     * via `fetchPage(first, after)` until the target is met or the connection
+     * is exhausted, so a large `--limit` (or `--all`, passed as `target === 0`)
+     * never issues one oversized request that Linear rejects as "Query too
+     * complex".
+     *
+     * `target === 0` means unlimited (fetch the whole connection). A positive
+     * target caps the total and trims any final-page overshoot. `fetchPage`
+     * returns `null` when the connection root is absent (e.g. an unresolved
+     * team) — treated as an empty result. A page that claims `hasNextPage` but
+     * returns zero nodes terminates the loop rather than spinning forever.
+     */
+    async paginateIssueNodes(target, fetchPage) {
+        const unlimited = target === 0;
+        const collected = [];
+        let after = null;
+        while (true) {
+            const remaining = unlimited
+                ? SAFE_ISSUE_PAGE_SIZE
+                : Math.min(target - collected.length, SAFE_ISSUE_PAGE_SIZE);
+            if (!unlimited && remaining <= 0) {
+                break;
+            }
+            const page = await fetchPage(remaining, after);
+            const nodes = page?.nodes ?? [];
+            collected.push(...nodes);
+            if (!unlimited && collected.length >= target) {
+                break;
+            }
+            const pageInfo = page?.pageInfo;
+            if (!pageInfo?.hasNextPage || !pageInfo.endCursor) {
+                break;
+            }
+            // Defensive: an empty page that still claims hasNextPage would loop
+            // forever on the same cursor. Stop instead.
+            if (nodes.length === 0) {
+                break;
+            }
+            after = pageInfo.endCursor;
         }
+        return unlimited ? collected : collected.slice(0, target);
+    }
+    async getIssues(limit = 25) {
+        const nodes = await this.paginateIssueNodes(limit, async (first, after) => {
+            const result = await this.graphQLService.rawRequest(GET_ISSUES_QUERY, { first, after, orderBy: "updatedAt" });
+            return result.issues ?? null;
+        });
         return nodes.map((issue) => this.transformIssueData(issue));
     }
     async getIssueById(issueId) {
@@ -577,9 +634,17 @@ export class GraphQLIssuesService {
                 : undefined;
         const limit = args.limit ?? 10;
         if (args.query) {
+            // Full-text search is relevance-ranked and then filtered client-side,
+            // so it cannot promise exhaustive `--all` semantics. Keep it to one
+            // bounded candidate page: the query embeds COMPLETE_ISSUE_FRAGMENT and
+            // an explicit large --limit would otherwise recreate the GraphQL
+            // complexity failure that chunking prevents on enumeration paths.
+            const fullTextLimit = limit === 0
+                ? SAFE_ISSUE_PAGE_SIZE
+                : Math.min(limit, SAFE_ISSUE_PAGE_SIZE);
             const searchResult = await this.graphQLService.rawRequest(SEARCH_ISSUES_QUERY, {
                 term: args.query,
-                first: limit,
+                first: fullTextLimit,
             });
             const nodes = searchResult.searchIssues?.nodes;
             if (!nodes?.length) {
@@ -616,28 +681,28 @@ export class GraphQLIssuesService {
         const filterArg = Object.keys(filter).length > 0 ? filter : undefined;
         const orderBy = args.orderBy ?? "updatedAt";
         if (finalTeamId) {
-            const teamScoped = await this.graphQLService.rawRequest(TEAM_SCOPED_FILTERED_ISSUES_QUERY, {
-                teamId: finalTeamId,
-                first: limit,
-                filter: filterArg,
-                orderBy,
+            const nodes = await this.paginateIssueNodes(limit, async (first, after) => {
+                const teamScoped = await this.graphQLService.rawRequest(TEAM_SCOPED_FILTERED_ISSUES_QUERY, {
+                    teamId: finalTeamId,
+                    first,
+                    after,
+                    filter: filterArg,
+                    orderBy,
+                });
+                return teamScoped.team?.issues ?? null;
             });
-            const nodes = teamScoped.team?.issues?.nodes;
-            if (!nodes?.length) {
-                return [];
-            }
             return nodes.map((issue) => this.transformIssueData(issue));
         }
-        const searchResult = await this.graphQLService.rawRequest(FILTERED_SEARCH_ISSUES_QUERY, {
-            first: limit,
-            filter: filterArg,
-            orderBy,
+        const nodes = await this.paginateIssueNodes(limit, async (first, after) => {
+            const searchResult = await this.graphQLService.rawRequest(FILTERED_SEARCH_ISSUES_QUERY, {
+                first,
+                after,
+                filter: filterArg,
+                orderBy,
+            });
+            return searchResult.issues ?? null;
         });
-        const filteredIssues = searchResult.issues;
-        if (!filteredIssues?.nodes) {
-            return [];
-        }
-        return filteredIssues.nodes.map((issue) => this.transformIssueData(issue));
+        return nodes.map((issue) => this.transformIssueData(issue));
     }
     // --- Private helper methods for field resolution ---
     async resolveTeamId(teamId, resolveResult) {
@@ -1116,9 +1181,15 @@ export class GraphQLIssuesService {
         if (!assigneeId || isUuid(assigneeId)) {
             return assigneeId;
         }
-        // Opt-in registry resolution (DEV-4872): try the identity registry first,
-        // falling back to the Linear-API user lookup below on a miss. EL-only,
-        // env-gated, fail-open — a non-EL install never reaches the network here.
+        // Opt-in identity resolution, falling back to the Linear-API user lookup
+        // below on a miss. Both layers are optional and fail-open — an install
+        // with neither configured never reaches the network here.
+        //   1. The resolver-command hook (DEV-5628) — brings its own credentials.
+        //   2. The older env-gated HTTP registry (DEV-4872).
+        const viaCommand = resolveViaCommand(assigneeId, loadConfig());
+        if (viaCommand) {
+            return viaCommand;
+        }
         if (isRegistryConfigured()) {
             const viaRegistry = await resolveViaRegistry(assigneeId);
             if (viaRegistry) {

package/dist/utils/issue-envelope-guard.d.ts

@@ -0,0 +1,50 @@
+/**
+ * Guard against overwriting an issue body with the issue's own JSON envelope.
+ *
+ * `issues get/read --format json` emits `JSON.stringify(transformIssueData(...))`
+ * — an object shaped `{ id, identifier, url, title, description, branchName,
+ * state, assignee, ... }`. Feeding that straight back into
+ * `issues update <ID> --description "$(... get <ID> --format json)"` (or the
+ * equivalent create) silently replaces the real markdown with the stringified
+ * envelope. Re-running on an already-corrupted issue re-wraps it, producing
+ * envelope-inside-envelope — so the damage deepens and recurs.
+ *
+ * This detector spots the envelope signature so the create/update path can
+ * block it with an actionable error. It is deliberately conservative: a plain
+ * markdown body never parses to an object carrying `identifier` plus an
+ * issue-only sibling key, so real descriptions pass untouched.
+ *
+ * See DEV-6315 (and the two victims it recovered, DEV-6092 / DEV-6042).
+ */
+export interface IssueEnvelopeMatch {
+    /** The `identifier` field carried by the detected envelope (e.g. "DEV-123"). */
+    identifier: string;
+    /** UUID carried by the envelope, when present. Used for self-match messages. */
+    id?: string;
+    /** Linear URL carried by the envelope, when present. */
+    url?: string;
+    /** True when the envelope's `description` is itself a nested envelope — the
+     * double-nesting signature of a re-corrupted body. */
+    nested: boolean;
+}
+/**
+ * Return a match when `text` parses as an issue-envelope JSON object, else null.
+ *
+ * An envelope is an object with a string `identifier` AND at least one of
+ * {@link ENVELOPE_SIBLING_KEYS}. Non-JSON text, JSON that isn't an object, and
+ * JSON objects without the signature all return null.
+ */
+export declare function detectIssueEnvelope(text: string): IssueEnvelopeMatch | null;
+/**
+ * Throw an actionable error when `text` looks like an issue's own JSON
+ * envelope being used as a description body. No-op otherwise, or when the
+ * caller passed the audited `--allow-json-description` override.
+ *
+ * `context` carries the audited override and, when known, the raw update target
+ * (identifier, UUID, or URL) so the message can flag the exact self-overwrite
+ * case without making a network request.
+ */
+export declare function assertNotIssueEnvelope(text: string | undefined, context?: {
+    allow?: boolean;
+    targetIssueRef?: string;
+}): void;

package/dist/utils/issue-envelope-guard.js

@@ -0,0 +1,110 @@
+/**
+ * Guard against overwriting an issue body with the issue's own JSON envelope.
+ *
+ * `issues get/read --format json` emits `JSON.stringify(transformIssueData(...))`
+ * — an object shaped `{ id, identifier, url, title, description, branchName,
+ * state, assignee, ... }`. Feeding that straight back into
+ * `issues update <ID> --description "$(... get <ID> --format json)"` (or the
+ * equivalent create) silently replaces the real markdown with the stringified
+ * envelope. Re-running on an already-corrupted issue re-wraps it, producing
+ * envelope-inside-envelope — so the damage deepens and recurs.
+ *
+ * This detector spots the envelope signature so the create/update path can
+ * block it with an actionable error. It is deliberately conservative: a plain
+ * markdown body never parses to an object carrying `identifier` plus an
+ * issue-only sibling key, so real descriptions pass untouched.
+ *
+ * See DEV-6315 (and the two victims it recovered, DEV-6092 / DEV-6042).
+ */
+/** Strong issue-envelope keys that, alongside `identifier`, distinguish the
+ * CLI output from unrelated ticket JSON. `description` is deliberately absent:
+ * `{ identifier, description }` is common enough outside Linear to avoid a
+ * false positive, while real `issues get` output always carries `url` and
+ * normally also `state` / `branchName`. */
+const ENVELOPE_SIBLING_KEYS = ["branchName", "state", "url"];
+/**
+ * Return a match when `text` parses as an issue-envelope JSON object, else null.
+ *
+ * An envelope is an object with a string `identifier` AND at least one of
+ * {@link ENVELOPE_SIBLING_KEYS}. Non-JSON text, JSON that isn't an object, and
+ * JSON objects without the signature all return null.
+ */
+export function detectIssueEnvelope(text) {
+    const trimmed = text.trim();
+    // Cheap prefilter: an envelope is a JSON object literal. Skips the parse for
+    // the overwhelmingly common markdown case.
+    if (!trimmed.startsWith("{")) {
+        return null;
+    }
+    let parsed;
+    try {
+        parsed = JSON.parse(trimmed);
+    }
+    catch {
+        return null;
+    }
+    if (typeof parsed !== "object" || parsed === null || Array.isArray(parsed)) {
+        return null;
+    }
+    const obj = parsed;
+    if (typeof obj.identifier !== "string" || obj.identifier.length === 0) {
+        return null;
+    }
+    const hasSibling = ENVELOPE_SIBLING_KEYS.some((key) => key in obj);
+    if (!hasSibling) {
+        return null;
+    }
+    const nested = typeof obj.description === "string" &&
+        detectIssueEnvelope(obj.description) !== null;
+    return {
+        identifier: obj.identifier,
+        ...(typeof obj.id === "string" ? { id: obj.id } : {}),
+        ...(typeof obj.url === "string" ? { url: obj.url } : {}),
+        nested,
+    };
+}
+/** Whether a raw CLI target (identifier, UUID, or Linear URL) names `match`. */
+function isSameIssueTarget(match, targetIssueRef) {
+    if (!targetIssueRef) {
+        return false;
+    }
+    const target = targetIssueRef.toLowerCase();
+    if (target === match.identifier.toLowerCase() ||
+        (match.id !== undefined && target === match.id.toLowerCase()) ||
+        (match.url !== undefined && target === match.url.toLowerCase())) {
+        return true;
+    }
+    // Linear issue URLs carry the canonical identifier as a path segment.
+    return target.split(/[/?#]/).includes(match.identifier.toLowerCase());
+}
+/**
+ * Throw an actionable error when `text` looks like an issue's own JSON
+ * envelope being used as a description body. No-op otherwise, or when the
+ * caller passed the audited `--allow-json-description` override.
+ *
+ * `context` carries the audited override and, when known, the raw update target
+ * (identifier, UUID, or URL) so the message can flag the exact self-overwrite
+ * case without making a network request.
+ */
+export function assertNotIssueEnvelope(text, context = {}) {
+    if (!text || context.allow) {
+        return;
+    }
+    const match = detectIssueEnvelope(text);
+    if (!match) {
+        return;
+    }
+    const isSelf = isSameIssueTarget(match, context.targetIssueRef);
+    const selfNote = isSelf
+        ? ` This is ${match.identifier}'s own envelope — the update would overwrite its body with itself.`
+        : "";
+    const nestedNote = match.nested
+        ? " (It is already a doubly-nested envelope — a sign this body was corrupted by an earlier run.)"
+        : "";
+    throw new Error(`Refusing to write a description that looks like an issue's JSON envelope ` +
+        `(a "${match.identifier}" object with an issue-only field such as branchName/state/url).${selfNote}${nestedNote}\n` +
+        `This is almost always an "issues get --format json" output accidentally piped into --description — ` +
+        `which silently destroys the real body (DEV-6315). ` +
+        `Pass a markdown body via --description-file <path>, or, if you genuinely mean to store this JSON, ` +
+        `re-run with --allow-json-description.`);
+}

package/dist/utils/output.js

@@ -348,6 +348,12 @@ export function outputSuccess(data) {
  * current limit) so the agent doesn't have to derive it.
  */
 export function warnIfTruncated(count, limit) {
+    // limit <= 0 means unlimited (--all / --limit 0, DEV-6312): a fully
+    // paginated result set can't be truncated, so never warn — and never
+    // emit the nonsensical "--limit 0" hint on an empty unlimited fetch.
+    if (limit <= 0) {
+        return;
+    }
     if (count !== limit) {
         return;
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@enrichlayer/el-linear",
-  "version": "1.41.1",
+  "version": "1.43.0",
   "description": "A pragmatic CLI for Linear.app — deterministic team/label/member resolution, structured issue validation, configurable term enforcement, and a GraphQL escape hatch.",
   "main": "dist/main.js",
   "types": "dist/main.d.ts",