Cline Kills Long-Running Commands at 30 Seconds: Here's the Fix

You're running a long command in Cline's Background Console, something like bit create or a big vitest suite, and right at the 30 second mark it dies with "Command timed out after 30000ms". Same command through the foreground terminal mode runs fine for up to an hour. Really annoying, and it's not your command's fault.

I dug into this after a user in issue #13246 couldn't get bit create to finish. The short version: there's a hard-coded 30 second timeout inside the SDK that Cline ships bundled with the extension, and the Background Console path uses it while the foreground path doesn't.

Why 30 seconds?

Cline's run_commands tool has two execution modes. The foreground one (vscodeTerminal) passes a 1 hour timeout to the SDK, straight from a constant that's literally 60 * 60 * 1000. The background path passes nothing, so the SDK falls back to its default. Two spots in the SDK source:

1. createShellTool does const timeoutMs = config.bashTimeoutMs ?? 30000;
2. the shell executor has timeoutMs = 30000 as a default, and that's what throws Command timed out after ${timeoutMs}ms

Both get compiled into the extension's dist/extension.js. I couldn't find any setting that controls it, which is probably why you've been hunting for one.

The fix: patch the bundle

Since there's no setting, the working workaround is patching the compiled extension. In your extensions folder (.vscode\extensions\saoudrizwan.claude-dev-<version>\next\dist\extension.js), do two replaces:

• e.bashTimeoutMs??3e4 → e.bashTimeoutMs??36e5 (the tool factory default)
• timeoutMs:r=3e4 → timeoutMs:r=36e5 (the shell executor default)

3e4 is 30000 ms, 36e5 is 3.6 million ms, which is one hour. Then reload VS Code. A minimal PowerShell version of that, run from the extensions folder:

$f = Get-ChildItem .\saoudrizwan.claude-dev-*\next\dist\extension.js |
  Sort-Object LastWriteTime -Descending | Select-Object -First 1
$c = Get-Content $f.FullName -Raw
$c = $c.Replace('e.bashTimeoutMs??3e4', 'e.bashTimeoutMs??36e5')
$c = $c.Replace('timeoutMs:r=3e4', 'timeoutMs:r=36e5')
Set-Content $f.FullName $c -NoNewline

Caveats, because there are always caveats. Those tokens are minified bundle output, so they can change between Cline releases. If a newer version doesn't match, grep for 3e4 and patch whatever the equivalent is. And any extension update will overwrite the patch, so either disable auto-update or keep the script around to re-run after updates.

The no-patch route

Don't want to touch the bundle? Run long jobs outside the Background Console. The regular terminal tool doesn't have this timeout, and on Windows you can fire a detached process and tail the log:

Start-Process cmd -ArgumentList '/c', 'your-long-command > C:\temp\job.log 2>&1' -WindowStyle Hidden

Then have Cline read the log file. Ugly, but it works, and it's what I'd do if patching the extension isn't your thing.

Upstream status

No official fix yet, as far as I can tell. The issue is still open, and a Cline team member suggested trying the "next" bundle override, which didn't help the reporter. So treat the patch as a stopgap. If you hit this, drop a comment on the issue and re-check it before you bother patching, since it could get fixed properly any day.

If your agent's background commands keep dying at exactly 30 seconds, it's not your shell, your script, or your machine. It's a hard-coded default inside the tool, and now you know exactly where it lives.