Review settings for using in repositories with long build times

[dsyme]

Some repositories (e.g. C++) have very long 5-10min build times.

This can cause problems with coding agents that have default timeouts for MCP/Bash tools or which have global time resource constraints. Token resources constraints are not so important as during thee long builds the models are not being used

I'd like to understand the matrix for this across different coding agents and how it relates to the GH-AW design and what settings we need to document or surface for different coding agents and whether there is a regular pattern here we should surface in a coding-agent neutral way (though probably not)

[dsyme]

/scout Please research this and post an issue comment here

[pelikhan]

/scout Please research this and post an issue comment here

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

Timeout handling for long-running builds (5–10 min, typical for C++) varies significantly across coding agents — ranging from fully configurable (Claude Code) to essentially hardcoded with no user control (GitHub Copilot coding agent, Devin). There is no universal pattern, which suggests GH-AW should document agent-specific guidance rather than trying to surface a single neutral abstraction.

Click to expand detailed findings

Research Findings

Claude Code

The most flexible of the group. Timeout is configurable at multiple layers:

Setting	Default	Where
BASH_DEFAULT_TIMEOUT_MS	120,000 ms (2 min)	~/.claude/settings.json or project .claude/settings.json
BASH_MAX_TIMEOUT_MS	~10 min	Same
MCP_TOOL_TIMEOUT	~60s	Same
Per-command inline	up to 600,000 ms (10 min)	Inline in the command prompt

Recommended config for long-build repos (in .claude/settings.json):

{
  "env": {
    "BASH_DEFAULT_TIMEOUT_MS": "1800000",
    "BASH_MAX_TIMEOUT_MS": "7200000"
  }
}

The per-command inline override (timeout 600000ms) has a hard cap of 10 minutes. For builds exceeding that, background execution (&) with polling is the workaround. There is also MCP_TIMEOUT (for MCP server startup) and MCP_TOOL_TIMEOUT (for MCP tool execution) — these are distinct from the Bash timeout.

Sources: [Claude Code Settings docs]((code.claude.com/redacted), Community solution thread, [Zenn article on timeouts]((zenn.dev/redacted)

---

GitHub Copilot Coding Agent

Much more constrained:

• Setup phase (copilot-setup-steps.yml): configurable via timeout-minutes (max 59 minutes)
• Coding phase command execution: hardcoded internal timeout of ~5–6 minutes — no documented way to extend it
• If a command exceeds this, Copilot assumes it's stalled and retries the commit, leading to retry loops

Available workarounds (no setting exists):

1. Move heavy pre-commit checks to post-commit CI
2. Skip slow checks when the committer is the Copilot agent (detect via env var or commit message)
3. Keep only lightweight (<3 min) checks in the coding phase

Sources: GitHub Community discussion, Copilot environment docs

---

Cursor AI

• Terminal/shell commands time out after roughly 10–20 seconds in some cases (possibly shorter for C++ build commands that don't produce output fast enough)
• Users with 5–10 min builds report the agent stopping builds mid-way, specifically before compilation finishes
• No official config to adjust the terminal tool timeout — the team has acknowledged this and is reportedly working on it
• Workaround: Instruct the agent (via .cursorrules) to never interrupt a running terminal, or have the user run the build manually and then paste terminal output into the chat

Sources: [Cursor bug report (Jan 2026)]((forum.cursor.com/redacted), [Cursor C++ timeout report]((forum.cursor.com/redacted)

---

Devin

• All commands time out after 5 minutes (hardcoded)
• Official docs explicitly state: "We do not recommend giving Devin commands that take longer than 5 minutes to run, as it will significantly slow it down"
• No configuration option exists to change this
• Workaround: Pre-cache the build (run it once in the VS Code terminal before verifying), or restructure the repo so incremental builds stay under 5 minutes

Source: [Devin Repo Setup docs]((docs.devin.ai/redacted)

---

Windsurf (Codeium)

• No specific timeout documentation found; uses a "Cascade" multi-step flow
• Long-running commands appear to work (reports of npm install, pip, etc. completing), but no official timeout specification found

---

General MCP Timeout Landscape

• MCP protocol itself doesn't mandate timeouts; clients set their own
• Common MCP client defaults: 10s (UI-TARS), 60s (various), 120s (Kiro)
• Amazon Bedrock AgentCore Gateway: 5-minute hard cap; AgentCore Runtime: 15 minutes (sync), 8 hours (async sessions)
• Pattern for handling long MCP operations: context messaging ("heartbeat" signals to keep connection alive), or async polling patterns

---

Summary Matrix

Agent	Bash/Terminal Timeout	MCP Tool Timeout	Configurable?	Recommended Workaround
Claude Code	2 min (default)	Separate env var	✅ Yes	BASH_DEFAULT_TIMEOUT_MS / BASH_MAX_TIMEOUT_MS in settings.json
GitHub Copilot Coding Agent	~5–6 min (hardcoded coding phase)	N/A	❌ No	Move heavy builds to post-commit CI
Cursor	~10–20s (terminal tool)	~200s	❌ No (WIP)	.cursorrules to avoid interrupting terminal; user runs builds manually
Devin	5 min (hardcoded)	N/A	❌ No	Pre-cache builds; keep incremental builds under 5 min
Windsurf	Unknown	Unknown	Unknown	N/A

Recommendations

• GH-AW should document agent-specific settings, not try to surface a single neutral pattern. The variation is too large for a unified abstraction to be useful.
• For Claude Code users: document the .claude/settings.json approach with BASH_DEFAULT_TIMEOUT_MS. This is the highest-leverage fix and is well-supported.
• For Copilot coding agent users: recommend structuring copilot-setup-steps.yml to pre-build or pre-warm caches during the setup phase (which allows longer timeouts), and keep build verification in CI rather than in the coding phase.
• For Cursor users: document a project .cursorrules snippet telling the agent not to interrupt long-running terminals.
• For Devin users: document the pre-caching pattern (running the build in the terminal once before starting a session).
• Consider adding a CLAUDE.md / AGENTS.md template section in GH-AW for long-build repos, with agent-specific stanzas. For example, for Claude Code: "Builds may take up to 10 minutes. Do not interrupt or re-run a build that is still in progress." and including the required settings.json env vars.
• Background build pattern (agent-neutral): Have the agent kick off the build as a background process (make -j8 > build.log 2>&1 &) and poll build.log for completion. This sidesteps most terminal timeout issues across agents.

Key Sources

• [Claude Code Settings Reference]((code.claude.com/redacted)
• Claude Code Timeout Solution Thread
• GitHub Copilot Coding Agent Timeout Discussion
• [Cursor Terminal Timeout Bug Report (2026)]((forum.cursor.com/redacted)
• [Devin Repo Setup: Command Timeouts]((docs.devin.ai/redacted)
• [AWS: Long-running MCP on Bedrock AgentCore]((aws.amazon.com/redacted)

Suggested Next Steps

1. Add a "Long Build Times" section to GH-AW documentation with per-agent timeout settings and workarounds
2. For Claude Code: expose BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS as recommended repo-level settings (.claude/settings.json)
3. For Copilot: document the setup-phase pre-build caching pattern to keep coding-phase commands short
4. Consider an AGENTS.md template in GH-AW starter repos that includes a "build patience" instruction and the relevant timeout configs for each agent

References:

• §22521741301

🔭 Intelligence gathered by Scout