builders · review · first seen Oct 26, 09:32 UTC

Cline ships CLI v3.0.74 with task and connection fixes

Cline shipped CLI v3.0.74 with fixes for attaching to running tasks, checking Hub health, and recovering from a dropped connection. A builder should care because these changes address runs that could duplicate, hang, or end before the model produced more than reasoning.

L0 · primary1 source5 claims checked5 min read

What shipped

Opening a task already running in another Cline app now attaches the CLI to that run. Previously, opening it could start a second run that could not be stopped. The release notes also say that if an app closes mid-task, requests waiting on it now fail with a clear message rather than hanging. This is a shipped change to how the CLI handles an existing run, not an announcement of a new task workflow. [1]

A frozen Hub health check now times out after 3 seconds, and the Hub is reported as not running. The release notes name cline hub status and cline doctor as commands that no longer hang on a frozen Hub. That gives a builder a bounded result from those checks instead of an indefinitely waiting command. The notes do not say that the timeout repairs the Hub or resumes work that depended on it. [1]

The CLI now retries a turn if the connection drops after the model has streamed only reasoning, rather than ending the run at that point. Model requests also retry at most 3 times instead of 5. Separately, the gemini provider no longer sends native Google Search with Gemini API keys. The release notes say the previous behavior caused a 429 quota error on every turn for free-tier keys on Gemini 3+, while on Gemini 2.x every Cline tool was dropped. Those are distinct fixes: one concerns a lost connection, one caps request retries, and one changes what is sent with a provider key. [1][2][3]

Why it matters if you build

If you move between Cline apps while a task is active, attaching to the existing run matters more than merely getting a second CLI view. The prior behavior could create a second run that could not be stopped. I would check this before relying on a cross-app handoff: open a task that is already running elsewhere and confirm that the CLI joins it. If an app closes mid-task, a clear failure for a waiting request is also preferable to a hang, but it still means that request failed. [1]

For a builder diagnosing a stalled Hub, the 3-second health-check timeout changes the immediate decision. cline hub status and cline doctor should return a not-running report rather than remain stuck on the check. That report is a diagnostic outcome, not evidence that the Hub is healthy. Treat it as a reason to investigate the Hub, not as a reason to assume the task can proceed. [1]

Connection recovery and retry limits pull in different directions. A turn that loses its connection after only reasoning has a retry path now, while any model request has a ceiling of 3 retries rather than 5. I would not read that as a guarantee that an interrupted run finishes: the notes identify a specific point of failure and a retry, not every possible disconnection. For Gemini API-key users, the Google Search change removes the specific request behavior tied in the notes to free-tier 429 errors on Gemini 3+ and dropped Cline tools on Gemini 2.x; it does not establish that every Gemini request will succeed. [1][2][3]

How to try it today

1. Use CLI v3.0.74 to open a task already running in another Cline app. Check that it attaches to that run rather than starting another one.
2. Run cline hub status and cline doctor against a frozen Hub. Check that the health check times out after 3 seconds and reports the Hub as not running.
3. If an app closes mid-task, check whether a request waiting on it fails with a clear message instead of hanging.
4. If a connection drops after the model has streamed only reasoning, check whether the turn retries rather than ending the run. Do not treat a different kind of drop as covered by this claim.
5. If you use a Gemini API key, check whether your workflow no longer sends native Google Search. Keep the model-request ceiling of 3 retries in mind when assessing a failure.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Cline CLI v3.0.74 attaches to a task already running in another Cline app instead of starting a second run.

   per GitHub releases · cline/cline (L0)
2. shipped L0 · primary

   Cline CLI v3.0.74 times out a frozen Hub health check after 3s.

   per GitHub releases · cline/cline (L0)
3. shipped L0 · primary

   Cline CLI v3.0.74 retries a turn when the connection drops after the model has streamed only reasoning.

   per GitHub releases · cline/cline (L0)
4. shipped L0 · primary

   Cline CLI v3.0.74 limits model request retries to 3 instead of 5.

   per GitHub releases · cline/cline (L0)
5. shipped L0 · primary

   Cline CLI v3.0.74 no longer sends native Google Search with Gemini API keys.

   per GitHub releases · cline/cline (L0)

What is not confirmed

The release notes do not establish how often builders encountered these failures, whether attachment works in every cross-app situation, or whether a retried turn will complete. They do not say that a 3-second timeout restores a frozen Hub. They also do not establish that removing native Google Search resolves other Gemini API-key errors. I would verify the behavior relevant to my own workflow rather than infer broader reliability from the listed fixes. [1][2][3][4]

Who should act, who should wait

Move now if your work involves opening active tasks in another Cline app, diagnosing a frozen Hub, recovering a reasoning-only turn after a connection drop, or using Gemini API keys in the affected request path. Those are the cases the shipped notes address, and each has a direct check you can make. Wait before changing a workflow on the assumption that all task handoffs, connection losses, or Gemini errors are fixed; the claims do not establish that wider result. If fewer retries affect your process, account for the stated ceiling of 3 rather than the previous 5. [1][2][3][4][5]

Sources

• CLI v3.0.74 — GitHub releases · cline/cline L0 · primary