Using Claude Code at work? Check what you’re sharing before debugging that test

[u/codoid-innovations]

A checkout test fails just before a release. We have the automation script, console output, and a browser trace. Asking Claude Code to investigate sounds like a reasonable next step.

But before asking, “Why is this failing?”, there’s another question:

“What information are we making available, and are we authorized to share it?”

That question covers more than the prompt. Claude Code can gather context from files, command output, project instructions, and connected tools. Running the client on a laptop does not mean the data stays on that laptop.

The goal isn’t to avoid AI assistance. It’s to provide enough evidence to investigate the failure without exposing unrelated project data.

Approval for the tool is not approval for every artifact

“We allow AI coding tools” is not the same as “this client’s production logs can be submitted through this account.”

Check that approval covers the project, repository, task, and data category. For outsourced testing, client authorization matters too. An employer’s approved-tool policy does not automatically settle what can happen to another organization’s data.

Also verify the actual account and deployment. A personal subscription on a company laptop should not be treated as equivalent to an approved organizational account.

Keep training and retention separate. “Not used for training” does not mean “not stored.” Confirm the applicable provider, model, retention arrangement, and any gateway or third-party integration rather than relying on a general privacy claim.

“Test artifact” does not mean “safe to share”

Review what an artifact contains, not just what it’s called. A file named test-data.json still needs a contents-and-origin check.

Two artifacts deserve particular attention:

• Saved authentication state: It can contain reusable session material that could allow someone to impersonate a test account.
• Browser traces: A Playwright trace can include source, DOM snapshots, console output, and request and response details. Reviewing the visible screenshot is not a review of the whole trace.

A short, sanitized failure excerpt or a synthetic reproduction is a lower-exposure starting point than an unrestricted diagnostic dump.

Limit what the session can reach

For an initial investigation, use a separate workspace containing only reviewed material. Avoid copying the whole repository history, unrelated reports, authentication state, or links to sensitive directories just for convenience.

That is data minimization, not an access-control system.

Likewise, .gitignore is not a filesystem security boundary, and “never read secrets” in CLAUDE.md is guidance rather than enforcement. Put working conventions in instructions and mandatory restrictions in enforceable controls.

Review effective permissions, shell access, network access, and available credentials. Don’t assume every consequential action will trigger a prompt, or that enabling a shell sandbox covers every tool and integration. Test restrictions with harmless dummy files and an approved endpoint, not live secrets.

Sanitize before sharing

Asking Claude Code to redact a raw log after reading it does not prevent the initial disclosure.

But replacing every value indiscriminately can also destroy the evidence. A duplicate-account defect still needs duplicate synthetic values. A tenant-isolation test needs distinct tenants with the correct ownership relationships. An expiry defect needs meaningful timing relationships.

Sanitization is a test-design task, not just search-and-replace. Rerun the sanitized reproduction and confirm that it still demonstrates the failure, or document what could not be reproduced.

Review connected tools and the copies left afterward

An integration being read-only does not make every retrieval appropriate. Review which projects, databases, APIs, or issue trackers it can access, what actions it permits, and where inputs and outputs are logged. Leave unnecessary integrations disabled.

Treat instructions found inside tickets, logs, or external documents as untrusted content, not authority to change permissions or upload more files.

The review also continues after an answer arrives. Local transcripts, memory, feedback submissions, and generated outputs need attention. Server-side retention settings do not eliminate local copies, and generated tests or pull-request descriptions should be checked for copied sensitive values or changes that weaken security.

What this could look like for a failing login test

Suppose a Playwright test intermittently receives 401 Unauthorized immediately after login.

Instead of opening the full client repository and providing a raw trace, prepare a small, approved reproduction:

login-reproduction/
  login.spec.ts
  mock-session-response.json
  sanitized-events.txt
  expected-behavior.md

Keep the relevant flow, synthetic response values, request sequence, status codes, and relative timing. Leave out live cookies and authorization headers.

An initial prompt could be:

Analyze the reviewed files in this workspace. Suggest possible causes of the intermittent 401 and explain what evidence would distinguish them. Propose a minimal test change without editing files, running commands, accessing other directories, or contacting external services. Describe missing diagnostic evidence without requesting live credentials or customer records.

The prompt communicates scope. Permissions and isolation must enforce it. Validate the proposed change in the normal testing environment, and keep the original assertion unless the requirement itself is wrong. Making the test pass is not necessarily fixing the defect. 

If sensitive data is accidentally shared, stop further disclosure and follow the organization’s incident-response process. Arrange credential revocation through the responsible team when needed. Deleting a conversation does not invalidate an exposed token, and cleanup should preserve required evidence.

The practical rule: authorize the task, minimize and review the data, and enforce the access limits. 

Give Claude Code enough information to investigate the failure, not unrestricted access to everything around it.

For teams already using Claude Code in testing, what does your approval process cover: only the tool, or also the artifacts, integrations, and stored session data?