Claude Code workflow acceptance criteria for software teams

A Claude Code implementation should be accepted only when the buyer can inspect what the workflow may access, how exceptional actions are approved, which model each delegated worker actually uses, and what evidence remains after a run. A successful demo is not enough. The acceptance decision should be tied to a named repository, runtime, configuration, identity set and tool inventory, with explicit tests for prohibited behavior and a responsible owner for every exception.

Anthropic’s changelog documents controls that can support this process: auto mode receives a rule concerning containment escape; the product can warn before its first read outside working directories; an available setting can block such reads; and a configuration variable can impose model selection across subagents. Those are verified product facts. The acceptance framework below is CreatikLab’s operational interpretation for software delivery, not a claim that Anthropic certifies a workflow or guarantees an outcome.

The official Claude Code changelog says the relevant release adds a containment-oriented rule to auto mode. The listed scenarios concern attempts involving cloud metadata credentials, avoidance of egress controls and reach across tenants. Auto approval is withheld unless the environment identifies the behavior as expected. The same entry documents a one-time decision point before the first file read outside working directories and names `permissions.blockReadsOutsideWorkingDirectories` as the setting for blocking those reads.

Anthropic also documents `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`. Its stated purpose is to apply the configured subagent model, or the main model, across subagents despite model substitutions requested when they are spawned or written into an agent definition. Gateway-discovered model entries can receive descriptions when `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY` is active. The changelog does not establish the safety, cost, speed or code quality of a buyer’s implementation, so none should appear as an acceptance promise.

CreatikLab recommends replacing broad language such as “configure autonomous coding” with a control contract. Start with five columns: resource, permitted action, forbidden action, approval owner and required evidence. Resources may include repository paths, environment variables, package registries, CI identities, cloud accounts, databases, local sockets, authenticated browser sessions and connected tool servers. If a resource is omitted, it should not quietly become available during implementation.

Define actors separately. The main session, each subagent, the gateway, source-control identity, external tools and human reviewer may operate under different controls. The provider must show where each policy is enforced rather than asserting that one setting governs the entire chain. The contract should also state who can change configuration, who can approve an exception and who can release an artifact. This prevents technical execution and risk acceptance from becoming an undocumented single role.

• Working-directory boundary — Test a benign read outside the approved path. Accept only when the observed prompt or block matches the written policy and filesystem telemetry confirms the result.
• Containment scenarios — Exercise only harmless simulations in an isolated lab. Accept when the workflow does not silently approve a prohibited scenario and any expected exception is narrowly documented.
• Subagent model policy — Spawn representative workers and compare their effective models with the approved inventory. Reject unexplained divergence.
• Gateway inventory — Reconcile displayed entries, stable identifiers and administrative records. Treat a description as a label, not proof of identity or commercial terms.
• Code-change control — Require the original instruction, commands, diff, tests and reviewer disposition for a representative change.
• Release separation — Demonstrate that producing a change does not automatically confer authority to deploy it. Preserve the approval and rollback references.

Each row needs a pass condition, an evidence location and a named decision maker. “Configured” is not a pass condition because it describes intent rather than behavior. “Observed in the agreed environment and matched by independent telemetry” is inspectable. When evidence is missing, the correct status is unresolved, not passed by assumption.

1. Record the installed Claude Code version and archive the configuration used for acceptance.
2. List every reachable repository, directory, tool, identity, secret class and external endpoint.
3. Create a disposable repository and synthetic credentials that cannot operate production systems.
4. Write expected outcomes for allowed, denied and approval-only scenarios before running tests.
5. Capture external-read behavior with both the session record and filesystem observation.
6. Run isolated containment simulations without using real cloud credentials or another tenant’s resources.
7. Create representative subagents and retain their tasks, effective models, tool calls and outputs.
8. Export the gateway model inventory when discovery is used and reconcile it with administration records.
9. Perform a controlled code change and retain the instruction, commands, diff, tests and review decision.
10. Demonstrate rollback using a reversible test artifact rather than relying on a verbal procedure.
11. Document every exception with scope, owner, rationale, review trigger and expiry condition.
12. Require engineering, security and the process owner to sign the final acceptance disposition.

The checklist should be delivered with raw evidence, not only a presentation. A buyer must be able to repeat the procedure after a configuration or integration change. Credentials and sensitive transcripts still require appropriate handling; acceptance evidence should prove control behavior without becoming a new source of exposed secrets.

Measure whether the operating boundary remains intact before trying to measure delivery speed. For every governed run, retain a workflow identifier, repository, configuration reference, effective main model, effective subagent models, tools invoked, external-read attempts, approvals, denials, files changed, test disposition and reviewer. Where a gateway is involved, preserve the selected entry or stable identifier rather than only its display text. Link every exception to the person who authorized it.

Useful control measures include runs with complete evidence, prohibited attempts denied, approval-only actions with a valid decision, changes satisfying the agreed tests, reviewer returns, unresolved model mismatches and rollback exercises completed. Define the denominator for every rate and preserve failed as well as successful runs. Compare a bounded pilot with the existing process using equivalent tasks; do not claim a productivity, security or cost improvement that the changelog does not demonstrate.

Accept when required resources are mapped, prohibited tests are denied, approval-only actions stop for accountable review, subagent models are observable, gateway entries are reconciled, code changes carry complete evidence and rollback works in the agreed environment. Conditional acceptance is appropriate when the workflow is useful but a dependency remains insufficiently isolated; the condition should reduce scope to read-only work, synthetic data, a disposable repository or another bounded mode until evidence closes the gap.

Reject when credentials are broader than the task, external reads lack a documented purpose, records cannot identify effective models, tools can bypass the stated boundary, production release can proceed without an accountable approval, or rollback has not been demonstrated. A rejection is not a verdict on Claude Code as a product. It means the proposed operating design cannot yet be accepted under the buyer’s own criteria.

• Do not assume one warning governs every path, command, tool or indirect read.
• Do not infer that blocking a file read also blocks network activity, tool calls or deployment credentials.
• Do not turn an expected containment exception into broad cloud authority.
• Do not infer a subagent’s effective model from its definition without checking the run record.
• Do not treat a gateway description as identity verification, security approval, price confirmation or eligibility evidence.
• Do not extrapolate a laptop test to CI, remote execution or another credential context.
• Do not let a successful demonstration replace branch protection, secret isolation, testing, peer review and rollback.
• Do not assume later configuration, model, gateway or tool changes remain covered by the original acceptance.
• Do not promise performance, savings, availability or security outcomes that Anthropic’s changelog does not establish.

The most common operational failure is boundary drift. A narrowly approved workflow gradually receives additional directories, tools and identities while retaining its original status. Define change triggers in advance: any expansion of reachable resources, alteration of model routing, new integration or changed deployment authority should reopen the relevant acceptance tests.

For a software engineering team, CreatikLab’s AI automation service can deliver a Claude Code control contract, asset and credential map, isolated acceptance harness, external-read test record, subagent model verification, gateway inventory, evidence-retention specification, approval workflow, exception register, measurement sheet and rollback rehearsal. These artifacts give engineering, security and procurement something concrete to inspect before they approve operation.

If the required boundary is not yet clear, hand the case to Lia with the repository type, runtime, connected tools, identity classes, deployment path and desired human approval points. Lia can route that context into a scoped diagnosis rather than treating “more autonomy” as a complete requirement. CreatikLab does not guarantee safety, savings, speed or code quality; the expert deliverable is a testable operating design and an evidence-based acceptance decision.

What should a team accept before a Claude Code workflow goes live?

Accept a defined operating boundary, not merely a working demonstration. The handover should identify allowed resources, prohibited actions, approval points, effective models, test evidence, accountable owners and a usable rollback procedure.

Which documented controls are relevant to acceptance testing?

Anthropic documents an auto-mode rule addressing containment escape, a prompt before the first read outside working directories, an option to block those reads and a variable that can impose the configured model across subagents.

Does passing the acceptance pack prove the workflow is secure?

No. It shows that a named configuration met agreed tests in a defined environment. It does not certify other repositories, credentials, integrations, versions or future changes.

How should external file access be tested?

Use a disposable environment and a harmless file outside the approved directory. Preserve the request, the displayed decision point, the operator response and independent filesystem telemetry. Repeat with blocking enabled.

What evidence is needed for subagents?

Keep a record of every representative subagent, its assigned task, its effective model, the tools it invoked and the resulting changes. A configuration declaration alone is not sufficient acceptance evidence.

What should an expert provider deliver?

Expect an access and credential map, versioned policy, isolated test harness, acceptance report, model and gateway inventory, evidence schema, exception register, approval design, incident procedure and rollback rehearsal.