[Shell] Command timeout is rigid (60s) and not configurable or adaptive

What version of Kimi Code CLI is running?

kimi, version 1.41

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

Kimi-k2.6

What platform is your computer?

Windows 64位

What issue are you seeing?

The Shell tool has a fixed default timeout of 60 seconds that cannot be configured by the user or overridden by the Agent on a per-command basis. For many legitimate development operations (especially with large repositories or complex Git operations), 60 seconds is insufficient, causing commands to be killed mid-execution and leaving the workspace in an inconsistent state.

Case 1: git submodule deinit on large submodule

ERROR: Command killed by timeout (60s)

Case 2: Large diff with submodule content
git show <commit> -- <submodule-path> produces large diff output that takes >60s to generate, then gets killed by timeout.

Case 3: Long-running build or test commands
Commands like npm run build, cargo build, make -j frequently exceed 60s. The build process is killed mid-execution, potentially leaving behind lock files or half-compiled artifacts.

What steps can reproduce the bug?

1. Work with a repository containing a large submodule (e.g., HAL library with thousands of files)
2. Ask the Agent to switch branches, clean the submodule, or inspect a commit with submodule changes
3. The Agent runs git submodule deinit -f <submodule> or git show <commit> -- <submodule-path>
4. Command exceeds 60s and is killed with "Command killed by timeout (60s)"

What is the expected behavior?

1. Adaptive timeout: The Shell tool should recognize command types that are known to be long-running (e.g., git submodule deinit, git clone, npm install, build commands) and automatically extend the timeout

2. Agent-controllable timeout: Allow the Agent to specify a longer timeout value in the Shell tool call for operations it knows will take time

3. User-configurable default: Provide a configuration option (e.g., in ~/.kimi/config.toml) to set a global default timeout:

   [shell]
   default_timeout_seconds = 120
   

4. Graceful handling: When a timeout does occur, provide the partial output collected so far (if any) to help with debugging

Additional information

Environment:

• OS: Windows 10/11 (also affects Linux/macOS for build commands)
• Repository: Large Git repository with submodules

Related Issues:

• #1341 - Windows Shell Commands Failing (commands timeout due to unrelated PowerShell profile issues)

• #2037 - Shell tool interactive commands cause terminal input corruption and hangs (also involves timeout behavior)

• #1117 - Shell tool interactive input support (feature request mentioning timeout as a blocker)

Suggested Fixes:

Option A: Command-type aware adaptive timeout
Maintain a mapping of command patterns to suggested timeouts:

LONG_RUNNING_COMMANDS = {
    r"git submodule (deinit|update|sync)": 300,
    r"git (clone|fetch --all)": 300,
    r"(npm|yarn|pnpm) install": 180,
    r"(docker|cargo) build": 300,
    r"git show .* -- .*": 120,  # submodule diffs
}

Option B: Allow Agent to specify timeout
Expand the Shell tool schema:

{
  "command": "git submodule deinit -f 17000628_HAL",
  "timeout": 300
}

Option C: User configuration
Add to config.toml:

[shell]
default_timeout_seconds = 120
max_timeout_seconds = 600

No implementation file or test is named. Start by locating the Shell tool's timeout handling and tool-call schema, then inspect how ~/.kimi/config.toml could provide the proposed default; reproduce with git submodule deinit or git show on a large repository. Done means supported timeout control, a configurable default, and preserved partial output when commands time out.