Improve network error detail and timeout behavior

[dubscode]

Summary

Please improve error reporting and timeout/process-exit behavior for failed Linear API requests.

Observed friction

During a real workflow, this command returned a very generic fetch error:

linear issues list --team BB --json --limit 100

Output:

{
  "ok": false,
  "entity": "issues",
  "action": "list",
  "error": {
    "code": "UNKNOWN",
    "message": "Fetch failed",
    "details": {}
  }
}

One list process also appeared to keep running after the failure, requiring process inspection/cleanup.

Requested improvements

• Include underlying network error details when safe: HTTP status, response body, DNS/socket timeout reason, or SDK error code.
• Add a bounded request timeout.
• Ensure failed commands always exit promptly.
• Include retry guidance only when the error is likely transient.
• Keep JSON errors machine-readable and stable.

Why this matters

Generic Fetch failed output is hard for both humans and agents to act on. It does not distinguish auth problems, workspace/team resolution problems, DNS/network issues, Linear API failures, or local runtime errors.

Better error detail would reduce unnecessary retries and make bug reports much easier to write.

[dubscode]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Improve Linear API network error details, timeouts, and failed-command exit behavior.

Current behavior:
Some failed Linear API requests surface as a generic Fetch failed error with little diagnostic detail. One observed list command also appeared to keep running after failure, requiring manual cleanup.

Desired behavior:
Failed API calls should return stable, machine-readable errors that include safe underlying details and should exit promptly. Network failures, auth failures, HTTP failures, SDK errors, and timeouts should be distinguishable where possible.

Key interfaces:

• Error normalization should preserve safe cause details such as HTTP status, SDK error code, response body summary, DNS/socket/timeout reason, or equivalent runtime cause.
• Linear API requests should have a bounded timeout.
• CLI actions should set a non-zero exit code on failure and should not leave hanging work after rendering an error.

Acceptance criteria:

• A simulated network failure produces JSON with a specific code/message/details rather than only UNKNOWN and Fetch failed.
• A simulated HTTP/API error includes safe status or SDK details in the JSON error envelope.
• Long-running or stalled requests are bounded by a documented timeout.
• Failed commands exit promptly with a non-zero exit code.
• Human error output remains readable while JSON output stays machine-readable.
• Tests cover network failure, timeout, and at least one non-network error path.

Out of scope:

• Retrying every failed request automatically.
• Logging secrets, tokens, full headers, or unsafe response bodies.
• Changing successful response envelope shape.

[dubscode]

This was generated by AI during triage.

Closed as completed by merged PR #15: #15