Can Your Developers Use Claude Code on Client Projects?

What could change for your business?

The aim is to move from a vague question about AI to a documented, bounded business decision. Relevant potential outcomes include:

• Define which client repositories may be processed.
• Review developer account type and permissions.
• Clarify deliverable rights and third-party code obligations.
• Create client approval and incident procedures.

Why is this question different?

This subject merits a distinct answer because it addresses source code, repositories and terminal operations rather than document chat. The relevant evidence and business decision differ from nearby pages in these ways:

• Source code, repositories and terminal operations rather than document chat.
• Client software agreements and deliverable IP obligations rather than generic vendor terms.
• Developer permissions, secrets, code reviews and deployment safeguards.

What supports the guidance?

This guide relies on first-party provider documentation and published institutional guidance, identified below. It does not claim to have inspected your private contract, account settings or security controls. The same product name may represent different plans, features and legal relationships. Therefore, no case study, result, approval or guarantee should be inferred from this page.

Detailed research: questions, evidence and practical safeguards

Direct answer: Before developers use Claude Code on client repositories, check the client agreement, protected source material, terminal and tool permissions, and the actual plan used. A coding assistant can work with local files and tools, so this is more than a chat confidentiality question.

Scope: This analysis focuses on the described business decision and the cited primary materials. It is not a substitute for review of an executed agreement, a specific account configuration or professional advice under the governing law. Each subsection identifies a reason the answer may change and a document or test that would help make the decision defensible.

Read the client agreement before exposing code

A software agency often holds repository access under confidentiality, security and intellectual-property clauses that control disclosure to subcontractors and outside services. Even if a coding tool offers commercial data protections, the agency may not have authorization to send restricted client material to that tool.

Evidence to examine: Review client agreements, security schedules, permitted subcontractors, repository classification and written approvals for use of external development tools. Practical response: Document the relevant client consent or contractual permission before connecting a sensitive repository or sharing source snippets.

Identify which Claude Code account runs the task

Claude Code may be accessed using consumer products, commercial organization arrangements or enterprise-managed configurations. The data treatment depends on that route. One developer using a personal account can create a different evidence and information-handling position from a firm-controlled commercial environment.

Evidence to examine: List authorized account types, authentication method, relevant legal terms and any configured retention or training exceptions. Practical response: Create a developer onboarding rule that forbids unapproved account switching during client work and provides a process for exceptional requests.

Relevant primary reference for this part of the review: Anthropic Legal Center — current commercial and service terms

Understand local tool and shell permissions

Claude Code can work with files and development tools under configured permissions. Settings can allow, require approval for, or deny actions depending on their scope. Broad permission settings may expose files beyond the task or permit unintended changes, even when generated code itself looks correct.

Evidence to examine: Review organization-managed settings, project settings, tool permissions, repository roots, execution commands and the actual environment in which coding assistance is used. Practical response: Apply least-privilege rules, protect secrets and test permission behavior in a non-production repository before enabling client work.

Protect credentials and sensitive configuration

Code repositories may contain secrets, credentials, connection strings or data samples. Their appearance in a tool context can create disclosure or operational risks. A company’s responsibility for protecting its systems is not discharged by relying solely on the AI provider’s account security documentation.

Evidence to examine: Check secret scanning, local environment files, repository exclusions, access logs, token issuance and the ability to revoke credentials after an incident. Practical response: Establish a clear policy on prohibited files and prompt inputs, with an escalation procedure for possible exposure of keys or customer data.

Relevant primary reference for this part of the review: Claude Code settings and permission documentation

Review ownership and provenance of deliverables

Software client contracts may promise assignment of work product, originality assurances, third-party-license compliance or a documented development method. Provider output-rights language does not establish that all generated code is original, free of licensing obligations or eligible for copyright protection.

Evidence to examine: Inspect existing IP clauses, open-source policy, human review records, dependency scans and any material generated code brought into the delivered application. Practical response: Require developers to review provenance and test code quality, documenting any material changes to contractual representations given to clients.

Separate code suggestions from deployment authority

A tool that edits a source file is not necessarily authorized to approve a production release, modify cloud infrastructure or access live customer information. Automation can blur the distinction between drafting, executing local commands, approving pull requests and changing the customer’s operating environment.

Evidence to examine: Map developer roles, branch protections, CI/CD permissions, production credentials, required approvals and the available audit trail. Practical response: Require human approval for consequential changes, maintain separation of duties and keep emergency rollback instructions accessible.

Relevant primary reference for this part of the review: Anthropic API and data retention documentation

Check plugins, extensions and external integrations

Development workflows can include code hosting, issue trackers, package registries, search services and external tools that each receive or act on information. A commercial AI policy does not automatically cover separate integration providers or their use of repository contents and account permissions.

Evidence to examine: Inventory connected services, their contractual basis, available OAuth scopes or tokens and whether they receive client data or source code. Practical response: Approve integrations on a client-by-client basis and revoke stale connections when a project ends or a contractor leaves.

Create a human code-review and test record

AI-generated software may compile while containing insecure patterns, licensing issues, incorrect logic or mismatched acceptance criteria. A developer or agency remains responsible for the work it approves and delivers under the customer’s agreement.

Evidence to examine: Record code reviews, static analysis, functional tests, client acceptance criteria, known limitations and the person approving merge or deployment. Practical response: Define a practical minimum review process for sensitive modules and avoid representing tool-generated output as independently verified engineering work.

Document a client-safe operating policy

The desired outcome is a defensible workflow specifying which projects use the tool, what information may be processed and which permissions are allowed. A single company-wide policy may be insufficient where different clients impose different audit, disclosure or security restrictions.

Evidence to examine: Maintain client-by-client permissions, applicable terms, repository risk classifications, test records and an incident contact. Practical response: Use a pilot project and review the outcomes before broad adoption; seek specialist technical testing where the actual system requires it.

Worked decision example

A development agency wants contractors to use Claude Code in a client’s private repository. The client agreement has strict disclosure restrictions and protected deployment credentials. The agency should check written permission, account terms, repository settings and pull-request approval before allowing tool access in the project.

The useful outcome is a written decision that identifies what information can be used, which supplier or professional rule applies, who approves the activity, and what evidence remains missing. The example does not establish that the hypothetical business has obtained a legal clearance, provider certification or binding professional approval.

Evidence checklist and owner matrix

What this analysis does not establish

No review of public documentation can prove the privacy posture of your particular account, determine client consent, ensure security, clear third-party intellectual-property rights or substitute for licensed local legal advice. The evidence needs to match the actual user, product, jurisdiction and contractual record. Technical penetration testing, professional certifications and vendor-endorsed approvals are not represented as completed services.

Primary sources and current product information

The following official sources provide starting points. Verify the current applicable version and any executed agreement before relying on a material proposition.

• Anthropic Legal Center — current commercial and service terms
• Claude Code settings and permission documentation
• Anthropic API and data retention documentation
• Anthropic commercial model-training policy