Stop computer bash commands on the computer itself
The sandbox ignores sandbox_execute_bash's timeout and runs every call in one shared shell session, so a command that never ended (a network read without a timeout, a prompt) kept running after the call gave up, and every later command on that computer, from any run, timed out behind it. Each command now runs in its own bash under coreutils timeout (at most ComputerCommandMaxSeconds, below McpToolTimeoutMs), reading no input, and says when it was stopped. Replies' env list says where each key comes from and that workspace, computer and install-wide envs reach every bot there, so bots stop telling users a workspace's keys must be set per bot. The computer prompt says installed programs may be gone after a restart. An empty open-only task list says closed tasks aren't shown, and update_task says when a status was already set. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
@@ -354,6 +354,13 @@ export const AppData = {
|
||||
* One MCP tool call gives up after this long without progress.
|
||||
*/
|
||||
McpToolTimeoutMs: 5 * 60 * 1000,
|
||||
/**
|
||||
* A bash command on a computer is killed there after at most this long
|
||||
* (`withCommandTimeout`), below `McpToolTimeoutMs`: the sandbox ignores
|
||||
* its own `timeout` and runs every call in one shell session, so a
|
||||
* command left running would hold up every later one on that computer.
|
||||
*/
|
||||
ComputerCommandMaxSeconds: 270,
|
||||
/**
|
||||
* MCP servers set up in Settings, under MCPs: a stdio server runs in
|
||||
* `DATA_DIR/<McpDataDir>/<id>` (its setup installs there, so it
|
||||
|
||||
Reference in New Issue
Block a user