{"record":{"id":"f1d2d11e486013e8","repo":"aaif-goose/goose","slug":"failed-to-spawn-goose-cli-main-thread","errorCode":null,"errorMessage":"Failed to spawn goose-cli main thread: {}","messagePattern":"Failed to spawn goose-cli main thread: (.+?)","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"critical","filePath":"crates/goose-cli/src/main.rs","lineNumber":48,"sourceCode":"\n    result\n}\n\nfn main() -> Result<()> {\n    #[cfg(windows)]\n    enable_windows_vt_processing();\n\n    let handle = std::thread::Builder::new()\n        .name(\"goose-cli-main\".to_string())\n        .stack_size(8 * 1024 * 1024)\n        .spawn(|| {\n            let runtime = tokio::runtime::Builder::new_multi_thread()\n                .enable_all()\n                .build()\n                .expect(\"Failed to build Tokio runtime\");\n            runtime.block_on(run())\n        })\n        .map_err(|e| anyhow::anyhow!(\"Failed to spawn goose-cli main thread: {}\", e))?;\n\n    handle\n        .join()\n        .map_err(|_| anyhow::anyhow!(\"goose-cli main thread panicked\"))?\n}\n","sourceCodeStart":30,"sourceCodeEnd":54,"githubUrl":"https://github.com/aaif-goose/goose/blob/3810898a7447ec3299be72e223d3570a7aabf0ab/crates/goose-cli/src/main.rs#L30-L54","documentation":"goose-cli's main() spawns a dedicated 8 MiB-stack thread that builds the Tokio runtime and runs the CLI (crates/goose-cli/src/main.rs:41-49). std::thread::Builder::spawn returns io::Error when the OS refuses to create the thread, and that error is wrapped into this anyhow error. This is a host-level failure, not a goose logic bug: the process could not even start its main worker thread.","triggerScenarios":"Thread creation fails with EAGAIN: per-process thread limit reached (ulimit -u), RLIMIT_STACK/memory limits preventing the 8 MiB stack allocation, cgroup/container memory exhaustion, or a sandboxed environment denying thread creation.","commonSituations":"Running goose in a constrained container/cgroup near its memory ceiling, a host at its nproc/thread limit under heavy load, or overly strict sandboxing (seccomp/LSM) of the CLI.","solutions":["Free system resources (reduce running threads/processes) and retry; check `ulimit -u` and raise the max user processes limit","Give the container/host more memory, or lower the stack_size requirement if you control the code","Check dmesg/container logs for OOM or seccomp denials if the spawn keeps failing"],"exampleFix":null,"handlingStrategy":"validation","validationCode":"// Before spawning heavy threads, sanity-check availability\nfn can_spawn_thread() -> bool {\n    std::thread::Builder::new()\n        .stack_size(1 << 20)\n        .spawn(|| {})\n        .map(|h| h.join().is_ok())\n        .unwrap_or(false)\n}","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Run goose with headroom on thread/memory limits (check `ulimit -u`, cgroup memory ceiling)","Avoid launching goose from parents near their process/thread cap","In containers, size memory limits above the ~8 MiB stack plus runtime working set"],"tags":["rust","threads","startup","resource-exhaustion"],"backgroundTag":null,"analyzedSha":"3810898a7447ec3299be72e223d3570a7aabf0ab","analyzedAt":"2026-08-16T10:14:26.282Z","schemaVersion":2},"datasetVersion":"2026-08-16T13:17:31.715Z"}