feat: Make Claude CLI timeout configurable, increase default, and bump version to 1.11.0

[steipete]

This PR introduces a configurable timeout for the Claude CLI via the CLAUDE_CLI_TIMEOUT_SECONDS environment variable, defaulting to 3600 seconds (60 minutes). It also updates the README and CHANGELOG accordingly. Version bumped to 1.11.0.

---

Note

Medium Risk
Moderate risk: changes execution timeout behavior for Claude CLI calls and upgrades core dependencies/build tooling (tsgo/pnpm), which could affect runtime behavior and CI/release reliability.

Overview
Adds configurable Claude CLI execution timeout via CLAUDE_CLI_TIMEOUT_SECONDS (default now 60 minutes) and wires it into tool invocation timeout handling.

Bumps release to 1.11.0 and refreshes docs/changelog to describe the new env var and updated tool/version messaging, plus minor markdown/formatting cleanups.

Modernizes project tooling: switches build/test scripts toward tsgo + pnpm, adds oxfmt/oxlint workflows, updates dependencies (notably @modelcontextprotocol/sdk and zod), and removes package-lock.json; GitHub Actions YAML is also reformatted for consistency.

^{Reviewed by Cursor Bugbot for commit 1e7f75c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pseudotensor]

Looks like a good change, any reason why not merged?

[steipete]

Mostly because I'm not using this anymore - buuuut I'll add that to my list and craft a new release soon, thanks for the ping!

[pseudotensor]

I see, is there an alternative to this repo in terms of built-in aspects of claude code? I couldn't find any other way to avoid the permissions issues while allowing (say) claude code or some other MCP client to use claude code itself as MCP server.

[steipete]

run claude with --dangerously-skip-permissions?

[pseudotensor]

For background, the existing sub agents or tasks cannot themselves run tasks. Yet I and others want this feature. maybe it's coming, but one never knows.

To solve this, I tried running

claude mcp add claude_code_unrestricted_server -- claude mcp serve

(claude mcp serve has no permissions options) including with settings.json changes for allowing everything.

The idea is then separate claude talking to this MCP can run full claude that also allows tasks inside.

This works, but fails due to permissions when that every is encountered, regardless of how one runs claude with --dangerously-skip-permissions or allowing all tools in settings.json or whatever.

Only your package was able to be used in this way.

I'm not even clear how people using cursor use the normal claude mcp server since it would be asking for permissions constantly.

[cursor]

LICENSE file corrupted by malformed regex replacement

The copyright line in the LICENSE file contains \g<1>2026 Peter Steinberger instead of Copyright (c) 2026 Peter Steinberger. This appears to be a regex replacement pattern (Python-style backreference syntax) that was accidentally left in the file during a find-and-replace operation. This corrupts the legal copyright notice, which could have implications for the project's licensing.

 

[cursor]

Escaped apostrophe causes visible backslash in tool description

In the tool description template, \\'re will produce \'re in the output string (with a visible backslash before the apostrophe). In JavaScript template literals, single quotes don't need escaping, so \\' produces a literal backslash followed by an apostrophe. The text "If you're stuck" will be displayed to users instead of the intended "If you're stuck". The apostrophe should simply be ' without any escaping.

 

[cursor]

Timeout detection fails due to missing signal/code properties

When Node.js spawn times out, the process is killed and the close event fires with code: null. The error object created in spawnAsync sets exitCode, stdout, and stderr but does not set signal or code properties. However, the timeout detection in the CallToolRequest handler checks for error.signal === 'SIGTERM' or error.code === 'ETIMEDOUT'. Since these properties are never set by spawnAsync, timeout errors are not properly detected, causing users to receive a generic "Claude CLI execution failed" message instead of the timeout-specific message. The tests pass because they mock spawnAsync to reject with the expected properties.

Additional Locations (1)

• src/server.ts#L265-L266

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 066a539. Configure here.}

[cursor]

CI broken: npm ci requires deleted package-lock.json

High Severity

The project was migrated to pnpm (packageManager field added, pnpm-lock.yaml exists, package-lock.json deleted), but both CI workflows still run npm ci, which strictly requires a package-lock.json to exist. This will cause every CI run to fail immediately. The workflows also reference npm run test:coverage and npm run test:unit, which internally invoke pnpm run build — that too will fail since pnpm isn't installed in the CI environment.

Additional Locations (1)

• .github/workflows/test.yml#L24-L25

 

^{Reviewed by Cursor Bugbot for commit 066a539. Configure here.}

[steipete]

Closing this as superseded by a focused extraction on current main: 0c3d630.

I did not merge this branch because it is now dirty against current main and mixes the timeout behavior with old version bumps, package-manager/tooling migration, workflow changes, and broad test rewrites.

What landed instead:

• Default Claude CLI execution timeout is now 60 minutes.
• CLAUDE_CLI_TIMEOUT_SECONDS can override it locally.
• Added parser validation tests and a handler test proving the configured timeout is passed to spawn.
• Updated README and changelog.

Proof: npm run build && npx vitest run passed with 62 tests, 3 skipped.