Claude Code

A team wants Claude Code to triage failing builds automatically on a build machine with no person watching. Each run must read the build log, inspect files in the checked-out commit and write one comment, and an operations rule states that a run must never stop waiting for an interactive approval, because a stalled run holds a build agent until it times out. The team also requires that the set of tools a run may use be identical on every build agent and visible to a reviewer before it changes. How should the team set this up?

• ARun Claude Code interactively on the build agent under a service account, and have an engineer approve tool use for the first run of each day so later runs inherit that decision.
• BRun Claude Code in its non-interactive headless mode with the permitted tools defined in a committed settings.json, so each run proceeds without prompting and the permission set is reviewed like code.check_circle Correct
• CRun Claude Code interactively but grant it unrestricted tool use on the build agent, since the agent is disposable and any unwanted action is discarded when the container is destroyed.
• DRun Claude Code with the permitted tools passed as arguments from the pipeline definition on each build agent, leaving the repository configuration untouched so the pipeline owns the decision.

Why A is wrong: Tempting because a single daily approval sounds like a small burden, but an interactive run still blocks whenever a new tool is requested, which is the stall the operations rule forbids.

Why B is correct: Correct because headless operation removes the interactive prompt that would stall the agent, and holding the permissions in committed configuration makes the tool surface identical across agents and reviewable before it changes.

Why C is wrong: Tempting because a disposable container does limit lasting damage, but unrestricted tool use gives no reviewable boundary and the build log is untrusted input that can steer the run.

Why D is wrong: Tempting because pipeline definitions are often version controlled too, but the permission set then differs per pipeline and drifts between agents, which breaks the stated requirement for one identical surface.

Four teams at one company use Claude Code and all four need it to query the same internal deployment tracker, which exposes a private HTTP API. The platform group owns the tracker and expects to change its query surface twice a year. Each team currently pastes an export of yesterday's deployment table into the session, and the teams have measured answers based on stale rows. The platform group must be able to change the query surface without any team editing its own configuration prose. Which arrangement fits that ownership boundary?

• AHave the platform group run an MCP server that exposes the tracker as tools, and have each team connect Claude Code to that server so queries run against the tracker at the moment they are asked.check_circle Correct
• BHave each team record the tracker's API shape in its own CLAUDE.md and ask Claude Code to call the endpoint directly, updating the four files whenever the platform group changes the surface.
• CHave the platform group publish a nightly export of the tracker to a shared location and ask each team to read that file at the start of a session rather than pasting it themselves.
• DHave each team write its own small integration script in its repository and instruct Claude Code to run that script whenever a question about deployments comes up during a session.

Why A is correct: Correct because the tool definitions live with the team that owns the tracker, so a change to the query surface ships from one place, and each call reads live data rather than a copy.

Why B is wrong: Tempting because CLAUDE.md is the right home for project conventions, but it puts the same integration detail in four files owned by four teams, which is exactly the coordination the platform group must avoid.

Why C is wrong: Tempting because it removes the manual paste and centralises the data, but the answers are still as old as the last export, so the measured staleness remains.

Why D is wrong: Tempting because a local script does fetch live data, but four independently maintained scripts drift and each must be updated when the platform group changes the surface.

A team runs Claude Code as a pull request review step. The step currently asks it to check formatting, import ordering, type errors and design consistency in one pass. The repository already has a formatter, a linter and a type checker that all run in seconds, and finance has set a per pull request cost ceiling that the review step now exceeds. Which change best fits the stated constraint?

• AKeep all four checks in the agent pass but ask for a shorter written report, so that fewer output tokens are generated on each pull request and the cost per review falls below the stated ceiling.
• BMove the whole review step to a nightly scheduled run over the day's merged pull requests, so the cost lands once per day rather than once per pull request while the same four checks are still performed.
• CKeep the four checks together and reduce spend by pinning the review step to the smallest available model, accepting that design consistency findings will be weaker than the ones produced today.
• DRun the formatter, linter and type checker as ordinary pipeline steps, fail the build on their output, and scope the Claude Code step to the design consistency judgement that no existing tool decides.check_circle Correct

Why A is wrong: Shortening the report is a real cost lever, but the expense here is the agent reading and reasoning over the whole diff for checks a tool already decides, so the saving is small and the reasoning cost remains.

Why B is wrong: Batching does reduce the number of runs, but it removes review from the point where it is useful and still pays an agent to decide things the formatter and the type checker already decide deterministically.

Why C is wrong: Model sizing is a legitimate lever, but the stem gives no evidence the quality bar tolerates it, and it leaves an agent doing mechanical work that a script performs faster and identically every time.

Why D is correct: The three mechanical checks are fully decidable by existing deterministic tools that run in seconds for no model spend, so scoping the agent to the one judgement call removes most of the cost while keeping the finding that only a model can produce.