What leaves your workstation when an AI coding CLI reads your repo? A 2026 privacy checklist

Posted on by

The surprising part of 2026 AI terminals is not that they can read a repository.

The surprising part is how many different meanings now hide behind one comforting phrase: local model support.

Sometimes it means the model runs on your laptop.

Sometimes it means your own API key is used.

Sometimes it means inference is routed into your cloud account.

Sometimes it means only part of the agent harness is local.

And sometimes, very politely, it means the exact thing your security team was worried about still leaves the machine.

Tiny wording difference.

Large compliance headache.

This article is a privacy checklist for teams evaluating AI terminals before connecting work repositories.

The anchor example is Warp, because Warp’s 2026 docs clearly separate privacy, BYOK, enterprise controls, and the still-open question of truly local model support.

I will also compare Wave Terminal where useful, because its docs explicitly describe local models, custom API endpoints, and BYOK-style configuration.

The goal is not to dunk on one terminal and crown another.

That would be fun for six minutes and useless by Monday.

The goal is to build a boring, repeatable checklist.

Before an AI terminal touches a work repo, you should know what data moves, where inference runs, who stores keys, what logs survive, and whether “local” means local enough for your actual policy.

The local-claim test

Vendor phrase Do not accept until you know
Local model support Whether inference actually runs on your machine
BYOK Whether prompts, logs, and tool traces still pass through the vendor
Enterprise routing Which cloud account receives data and who controls retention
Local agent Whether file reads, shell state, and repo context leave the device

If the terminal also connects MCP tools, pair this privacy checklist with the MCP security isolation checklist.

May 7 refresh: treat CLI telemetry as repo-adjacent data

This May 7, 2026 refresh adds a narrower question:

what leaves the workstation when an AI coding CLI reads a repository?

SPERIXLABS published a lab capture on April 11, 2026 that ran several LLM coding CLIs through a transparent proxy and grouped observed outbound traffic into channels such as model API calls, product analytics, OpenTelemetry traces, third-party log sinks, identity and OAuth flows, MCP and plugin ecosystem traffic, and local helper endpoints.

That post is useful because it separates “prompt content” from “metadata.”

It also has a limitation: it is one captured lab session, not a permanent vendor audit.

So do not turn it into a universal verdict.

Turn it into a checklist.

Data class Privacy question to ask before connecting a work repo
Prompt and completion content Which model endpoint receives code, logs, shell output, or snippets?
Product analytics Which events are sent when tools run, commands start, or files are suggested?
OpenTelemetry traces Do spans include hostnames, OS data, token counts, RPC names, or repo structure?
Third-party log sinks Is traffic going only to the vendor, or also to observability providers?
Identity and OAuth Which scopes are granted, and can private repo access ride along?
MCP calls Does the client call MCP servers directly, through a vendor proxy, or through your own gateway?
Local helpers Are localhost services truly local, or do they summarize and forward state later?

The takeaway is not “never use an AI coding CLI.”

The takeaway is to review envelopes, not only content.

Even when code text is not stored, tool names, repo file counts, token counts, local host metadata, model names, permission modes, and MCP target IDs may still be operationally sensitive.

That is especially true for security teams evaluating private repositories, unreleased products, incident response work, or regulated customer systems.

The practical control is simple:

  1. classify the repo before opening it in an AI CLI,
  2. run a short network capture in a disposable repo,
  3. list every outbound host and path,
  4. separate prompt payloads from telemetry envelopes,
  5. verify opt-out and enterprise retention behavior,
  6. document MCP proxy paths and OAuth scopes,
  7. block or route anything that violates the repo’s data class.

Tiny lab test first.

Then policy.

Then broader rollout.

That order saves meetings, and meetings are where human happiness goes to do paperwork.

2026-05-06 refresh: the checklist now treats agent permissions and MCP servers as first-class privacy controls, not optional developer preferences.

Claude Code’s current settings documentation lists permissions.deny as the mechanism for excluding sensitive files such as .env, secrets/**, credential files, and build artifacts from tool access.

Its security documentation also says MCP servers should come from providers you trust, and that Anthropic does not manage or audit third-party MCP servers.

That matters for AI terminals because a “local” coding workflow can still become a networked workflow through one approved MCP server, one broad file-read permission, or one repo-wide codebase indexing toggle.

So the practical test is no longer only “does the model run locally?”

It is “does the full agent path keep repo content, shell output, secrets, embeddings, and tool calls inside the boundary your team actually approved?”

The 2026 problem: terminals became repo-facing AI clients

Classic terminals were sensitive because commands, paths, tokens, SSH output, and production logs pass through them.

AI terminals add a second sensitivity layer.

They may collect context from the current shell state.

They may read nearby files.

They may index a codebase.

They may send prompts to hosted model providers.

They may execute commands on your behalf.

That does not automatically make them bad.

It does mean “we only use it for command help” is no longer a complete answer.

In Warp’s current agent documentation, AI features can be disabled globally, and the docs say those features send input data to LLM providers through their APIs.

That sentence matters.

It tells you the agent feature is not just a local autocomplete toy.

It is a networked AI workflow unless you have a specific configuration that changes that route.

Warp’s enterprise security overview gives an even cleaner split.

Code and files stay on the machine unless features that transmit them are explicitly used.

Codebase Context indexing sends code to Warp’s servers to generate embeddings.

Agent requests go to contracted LLM providers under enterprise Zero Data Retention arrangements.

Bring Your Own LLM, or BYOLLM, routes requests through Warp’s servers to customer cloud infrastructure where inference runs.

Those are four different privacy postures.

They should not be collapsed into one phrase.

A terminal can be excellent UX and still need serious data classification.

That is the adult version of the hype cycle.

Annoying, yes.

Useful, also yes.

Define “local” before anyone says yes

The first checklist item is boring enough to save a procurement meeting.

Ask: what exactly is local?

Local UI is not local inference.

Local key storage is not local inference.

Local repository cloning is not local inference.

Local execution is not necessarily local context handling.

Local model support should mean the model process can run on a machine or network boundary you control, without prompt or code context transiting a vendor server.

If a request leaves the laptop, it may still be secure.

If a request enters your company’s cloud account, it may still satisfy your internal policy.

If a request goes through a vendor proxy, it may still be covered by ZDR and contracts.

But those are not the same as truly local.

Warp’s April 30, 2026 GitHub discussion is useful because it shows the architecture issue directly.

Warp’s maintainer described local model support as non-trivial because the harness is split between the open-source Rust client and a server-side Golang component.

The options under discussion include porting the harness to the client, supporting external harnesses, building a lighter local harness, or routing local model requests through the server and back to the client.

That list is a privacy checklist in disguise.

One option is truly local.

One option depends on another local or self-hosted harness.

One option may be a partial local harness.

One option still involves server transit.

The UI might look the same in all four cases.

The data route does not.

That is the whole ballgame.

The three privacy tiers for AI terminals

For practical review, I split AI terminal setups into three tiers.

Tier 1 is hosted model routing.

Tier 2 is BYOK or enterprise cloud routing.

Tier 3 is truly local or self-hosted inference with no vendor server in the prompt path.

Tier 1 can be perfectly acceptable for public repos, personal projects, learning, and low-risk automation.

It is the fastest setup.

It usually has the best model quality.

It often has the cleanest product experience.

It also means prompts and selected context leave the device.

That needs to match the repo’s data class.

Tier 2 is more controlled but not automatically private.

BYOK may route directly to your chosen model provider.

Enterprise BYOLLM may route inference into your own cloud.

Admin controls may restrict models and sharing.

But the prompt path, logs, provider retention settings, and vendor control plane still need review.

The label “your key” does not magically erase all data handling questions.

Tiny sticker, giant audit form.

Tier 3 is the privacy-first target.

The model runs locally or inside an approved private environment.

The prompt does not need to cross the vendor’s servers.

The harness, tool calls, command execution, memory, logs, and embeddings remain within the approved boundary.

This is harder.

It may be slower.

It may require smaller models.

It may lose hosted-agent niceties.

But for regulated repos, unreleased product strategy, customer data, secrets-heavy infrastructure, or incident response work, Tier 3 is often the difference between “approved” and “please uninstall that today.”

Warp in 2026: what the official docs actually say

Warp’s documentation is unusually useful because it does not pretend all privacy modes are the same.

The privacy page says Warp applies secret redaction in AI interactions.

It also says telemetry must be enabled to use AI features on the Free plan, while paid plans can opt out and keep using Warp, including AI.

For Business and Enterprise plans, the page says Zero Data Retention applies and that no AI interaction or console data is collected.

That is a meaningful difference between plan tiers.

It should be in your review notes.

The enterprise security overview says code and files stay on your machine unless you explicitly use features that transmit them.

Examples include Codebase Context indexing, session sharing, and Warp Drive team resources.

It says Codebase Context sends code to Warp’s servers to generate embeddings.

It says raw code is not stored, while resulting embeddings are retained.

That is not scary by itself.

It is just not the same as never sending code.

If your company’s policy treats embeddings derived from proprietary source as sensitive, this point matters.

The same overview says agent requests are sent to contracted LLM providers such as Anthropic, OpenAI, and Google with ZDR agreements for Enterprise teams.

It also says telemetry data, when collected, is retained indefinitely for analytics and debugging.

Do not mix those two rows together.

AI interaction handling and telemetry handling can have different retention models.

Your checklist should separate them.

Warp’s BYOK page says paid plans can bring API keys for OpenAI, Anthropic, and Google models.

It says those keys are stored locally on the device and never synced to the cloud.

It also says Warp uses those keys to directly route agent requests to the configured provider.

The caution is important.

Warp cannot enforce ZDR for requests sent through your API keys.

If your provider account does not have ZDR enabled, requests may be retained according to that provider’s terms.

BYOK gives you billing and provider control.

It does not automatically give you enterprise retention.

That sentence should be taped to every “we use our own key, so we’re fine” Slack thread.

Gently.

Maybe with nicer tape.

Warp model choice is not the same as arbitrary local model support

Warp’s Agent FAQ says Warp supports a curated list of LLMs from providers like OpenAI, Anthropic, and Gemini.

The Model Choice page is the place the docs point to for switching between supported models.

BYOK also points users back to model choice.

This means model flexibility exists, but it is bounded by supported provider integrations.

As of the 2026-05-03 KST writing context for this draft, Warp’s official local and arbitrary model support is being discussed in GitHub discussion #9619.

That discussion is not the same as shipped product documentation.

It is still a primary source for roadmap thinking because it is opened by Warp’s maintainer in the official repository.

But a procurement checklist should label it correctly.

Roadmap discussion is not production support.

If a team needs Ollama, LM Studio, LocalAI, vLLM, or an OpenAI-compatible local endpoint today, it should ask for a working documented path, not just a promising discussion.

This is where language gets slippery.

“Open source client” is not the same as “local model support.”

“BYOK” is not the same as “arbitrary endpoint.”

“Enterprise BYOLLM” is not the same as “no vendor control plane.”

“Self-hosted execution plane” is not the same as “self-hosted inference plane.”

They may overlap in a future architecture.

They should not be assumed to overlap in today’s security review.

Wave Terminal as a useful contrast

Wave Terminal’s docs describe Wave AI modes with local models, custom API endpoints, and alternative AI providers.

The page says modes are configured in ~/.config/waveterm/waveai.json.

Each mode defines the model, API endpoint, authentication, and display properties.

That is the kind of configuration surface local-model users usually expect.

It also says provider-based configuration can simplify common provider defaults.

The important point is not “Wave wins.”

The important point is that Wave’s docs expose a different privacy primitive.

You can point the AI feature at a local endpoint or custom endpoint as a first-class mode.

For teams already running local inference services, that matters.

It gives security reviewers something concrete to inspect.

What endpoint is used?

Where is the auth secret stored?

Which model is selected?

Does the tool call path stay inside the host or VPC?

Which logs are written by the terminal and by the model server?

With any AI terminal, that is the shape of the review.

The product name changes.

The questions do not.

Privacy checklist before connecting a work repository

Use this section as the preflight form.

It is intentionally plain.

Fancy diagrams are nice, but the repo is either allowed or it is not.

1. Classify the repository first

  • Is the repository public, internal, confidential, regulated, or customer-data adjacent?

  • Does it contain unreleased product logic, pricing strategy, customer integrations, or incident response scripts?

  • Does it include infrastructure-as-code that reveals cloud topology?

  • Does it include test fixtures copied from production data?

  • Does it include prompts, evaluations, or agent instructions that are themselves proprietary?

  • Does it include vendor credentials in local .env files, shell history, or config folders outside Git?

  • Does the terminal agent see only Git-tracked files, or can it inspect the entire working directory?

  • Does the repo policy allow code snippets to be sent to hosted AI providers?

  • Does the policy allow derived embeddings to be stored by a vendor?

  • Does the policy distinguish between source code, generated patches, logs, and transcripts?

Example:

A public CLI tool can probably use hosted model routing with basic caution.

A private payments service with staging credentials in local config should start from deny-by-default.

Different repo.

Different answer.

2. Draw the actual data path

  • Where does the prompt originate?

  • Does the terminal add shell output automatically?

  • Does it add current directory files automatically?

  • Does it index the whole codebase?

  • Does it upload code to generate embeddings?

  • Does it send screenshots, terminal blocks, command history, or selected text?

  • Does traffic go directly to a model provider?

  • Does traffic pass through the terminal vendor’s servers?

  • Does traffic pass through a company proxy?

  • Does inference run in the vendor cloud, model provider cloud, customer cloud, or local machine?

  • Does the terminal vendor store transcripts?

  • Does the model provider store prompts?

  • Does the model provider train on prompts?

  • Does an enterprise ZDR agreement cover this exact route?

Example:

Warp BYOK and Warp Enterprise ZDR are different routes.

Do not approve one because you read the docs for the other.

That is how privacy reviews become archaeology.

3. Separate BYOK from ZDR

  • Is BYOK available on the plan?

  • Which providers are supported for BYOK?

  • Are keys stored locally or synced?

  • Can admins enforce BYOK settings at the organization level?

  • Does the provider account have Zero Data Retention enabled?

  • Does the provider account have data training disabled?

  • Are API logs retained by the provider?

  • Are requests routed directly to the provider or through the terminal vendor?

  • Does BYOK apply to local agents, cloud agents, or both?

  • Are “auto model” routes excluded from BYOK?

Example:

Warp’s BYOK docs say keys are stored locally and never synced to the cloud.

They also say Warp cannot enforce ZDR for requests sent through your API keys.

So the checklist answer is not “BYOK equals private.”

The answer is “BYOK shifts retention responsibility to the provider account configuration.”

Slightly less catchy.

Much more accurate.

4. Check whether “local model” means no server transit

  • Does the model process run on the same machine?

  • Does the model process run on a company-managed server?

  • Does the terminal contact a vendor server before contacting the local model?

  • Does the agent harness run locally?

  • Does the tool execution loop run locally?

  • Does planning run locally?

  • Does memory or transcript storage run locally?

  • Does the terminal support arbitrary OpenAI-compatible endpoints?

  • Does it support Ollama or another local runtime directly?

  • Does it support custom endpoint auth without leaking keys?

  • Does it work offline after setup?

  • Does any feature require an account login or cloud control plane during use?

Example:

In Warp’s official discussion, one possible implementation was routing local model requests through a server and back to the client.

For some users, that may be a useful bridge.

For strict privacy use cases, that is not “local enough.”

The key phrase is no server transit.

Put it in the requirement.

5. Review codebase indexing separately from chat

  • Can the AI terminal answer questions without indexing the whole repository?

  • If indexing is enabled, which files are included?

  • Are .gitignore, .ignore, or product-specific ignore files respected?

  • Are embeddings generated locally or remotely?

  • Are raw files stored?

  • Are embeddings stored?

  • Can embeddings be deleted?

  • Are embeddings scoped per user, team, workspace, or repository?

  • Can admins disable indexing?

  • Can users accidentally enable indexing for a restricted repo?

  • Is there an audit event when indexing happens?

Example:

Warp’s enterprise overview says Codebase Context sends code to Warp’s servers to generate embeddings, raw code is not stored, and embeddings are retained.

That may be acceptable.

It may also require legal review.

The checklist should not treat embeddings as invisible fairy dust.

They are derived data.

Derived data still has a data owner.

6. Audit secret handling without trusting vibes

  • Does the terminal redact API keys?

  • Does it redact SSH keys?

  • Does it redact certificates?

  • Does it redact passwords in command output?

  • Can admins configure custom secret patterns?

  • Are redaction rules applied before data reaches model providers?

  • Are redaction failures logged?

  • Can users inspect what was actually sent?

  • Are shell history files included in context?

  • Are .env, .npmrc, .pypirc, kubeconfig, Terraform state, or cloud credentials excluded by default?

  • Are tokens hidden in screenshots or copied terminal blocks?

Example:

Warp’s docs say secret redaction is applied in AI interactions and can cover API keys, tokens, passwords, SSH keys, certificates, and custom patterns for enterprise admins.

Good.

Still verify with test tokens before using a real repo.

Security by documentation alone is just fan fiction with better formatting.

7. Verify command execution boundaries

  • Can the agent run commands automatically?

  • Is there an approval prompt before commands execute?

  • Can approval be enforced by admins?

  • Can destructive commands be blocked?

  • Can network commands be blocked?

  • Can file writes be scoped to a workspace?

  • Can the agent read outside the repository root?

  • Can it access SSH agents, credential helpers, or keychains?

  • Can it use MCP servers or plugins that expand permissions?

  • Is there a log of commands proposed and commands executed?

  • Can that log be exported for review?

Example:

An AI terminal with local inference can still be dangerous if it can execute unrestricted commands.

Privacy is not only about where prompts go.

It is also about what the agent can do after reading them.

Local chaos is still chaos.

It just has lower latency.

8. Check team controls, not just personal settings

  • Can admins disable AI features globally?

  • Can admins restrict model choices?

  • Can admins enforce telemetry settings?

  • Can admins configure secret redaction?

  • Can admins disable sharing links?

  • Can admins prevent cloud conversation storage?

  • Can admins restrict codebase indexing?

  • Can admins control cloud agent access?

  • Can admins see policy drift across users?

  • Is there SSO?

  • Is there SCIM?

  • Is there role-based access control?

Example:

Warp’s enterprise overview describes admin controls for privacy, sharing, AI behavior, models, and platform settings.

That is useful for companies.

But if BYOK is only user-level for a given plan or feature, that is a different governance story.

Personal settings are not policy.

They are preferences with a nice jacket.

9. Decide what logs are allowed to exist

  • Are AI transcripts stored locally?

  • Are AI transcripts stored in the vendor cloud?

  • Are command outputs stored?

  • Are crash reports enabled?

  • Are analytics enabled?

  • Are telemetry events high-level only?

  • Do telemetry events include user-generated content?

  • How long are telemetry records retained?

  • Can users delete conversations?

  • Can admins export or delete team data?

  • Are logs available to vendor support?

  • Are support bundles sanitized?

Example:

Warp’s privacy docs separate telemetry, AI interactions, console inputs, and plan-specific controls.

Your review should do the same.

One retention answer for everything is usually a smell.

Sometimes the smell is harmless.

Sometimes it is the beginning of a very long meeting.

10. Test with a fake sensitive repository

  • Create a temporary repository.

  • Add fake API keys.

  • Add fake customer records.

  • Add fake infrastructure files.

  • Add fake internal docs.

  • Ask the terminal agent to summarize the repo.

  • Ask it to debug a command.

  • Ask it to generate a patch.

  • Inspect network traffic if your security team supports that workflow.

  • Inspect local logs.

  • Inspect vendor dashboards.

  • Confirm whether fake secrets were redacted.

  • Confirm whether ignored files were ignored.

  • Confirm whether transcripts can be found later.

Example:

Do not discover context behavior on the real monorepo.

That is like testing a fire alarm by burning the office carpet.

Technically educational.

Still not the move.

A simple decision table

Use hosted AI terminal mode when the repo is public, low-risk, and your company allows hosted AI use.

Use hosted mode when productivity matters more than strict locality and the vendor’s privacy terms match your risk level.

Use BYOK when you need billing control, provider account control, or access to approved provider settings.

Use BYOK only after confirming retention settings in the provider account.

Use enterprise ZDR when your organization has a contract that covers the exact model route.

Use enterprise admin controls when individual developer settings are not enough.

Use BYOLLM or customer-cloud inference when the company wants inference inside its own cloud boundary but can tolerate vendor orchestration.

Use self-hosted execution when repository clones, build artifacts, runtime secrets, and container state must remain on your infrastructure.

Use truly local model support when prompt context must not transit a vendor server.

Use no AI terminal at all when the repository contains restricted data and the tool cannot prove an acceptable route.

That last option is not anti-AI.

It is just engineering.

The best tool for a blocked policy is not another prompt.

It is a smaller blast radius.

What I would ask a vendor before approval

Question 1: When the agent answers a question about this repo, what exact data leaves the machine?

Question 2: Does shell output leave the machine?

Question 3: Does command history leave the machine?

Question 4: Does untracked local config leave the machine?

Question 5: Does codebase indexing upload files?

Question 6: Are embeddings generated locally or remotely?

Question 7: Are embeddings retained?

Question 8: Can embeddings be deleted per repository?

Question 9: Does BYOK route directly to the provider or through your infrastructure?

Question 10: Can your company enforce ZDR when BYOK is used?

Question 11: Which model providers have contracted ZDR?

Question 12: Are prompts ever used for training or product improvement?

Question 13: Are AI interactions collected on free plans?

Question 14: Can paid plans opt out of telemetry while keeping AI enabled?

Question 15: Can admins enforce model restrictions?

Question 16: Can admins disable AI globally?

Question 17: Can admins disable sharing and cloud conversation storage?

Question 18: Can admins define custom secret patterns?

Question 19: Can developers inspect the payload before it is sent?

Question 20: Can the agent run commands without approval?

Question 21: Can command execution be limited by policy?

Question 22: Can the agent read outside the repo root?

Question 23: Can the agent use external MCP servers or plugins?

Question 24: Are support logs sanitized?

Question 25: Does local model support require vendor server transit?

Question 26: Does local model support work offline?

Question 27: Does arbitrary endpoint support include local OpenAI-compatible endpoints?

Question 28: Is the agent harness local, server-side, or split?

Question 29: Which parts of the client are open source?

Question 30: Which parts of the agent service are not open source?

If a vendor can answer those cleanly, great.

If the answer is “trust us, it is secure,” pause.

Not forever.

Just long enough to get the boring diagram.

The boring diagram is where the truth usually lives.

Practical setup patterns

Pattern A: public repo plus hosted model.

This is fine for many developers.

Use the default hosted model route.

Keep secrets out of the working directory.

Disable broad indexing unless you need it.

Treat transcripts as non-sensitive but still professional.

This is the smoothest experience.

It is also the least interesting privacy case.

Pattern B: internal repo plus enterprise ZDR.

Use the vendor’s enterprise plan.

Confirm the contracted model providers.

Confirm admin controls.

Disable public sharing.

Set custom secret redaction.

Decide whether codebase embeddings are allowed.

Document the retention model.

This is the normal company path.

Less glamorous.

More likely to survive audit season.

Pattern C: internal repo plus BYOK.

Use approved provider accounts.

Enable provider-side ZDR where available.

Confirm requests are not silently routed through auto-model modes.

Train developers to select the model with the key indicator.

Review billing and API logs.

Do not assume terminal vendor ZDR applies to your provider account.

This setup is flexible.

It is also easy to misconfigure.

Pattern D: restricted repo plus local endpoint.

Use a terminal that supports local or custom endpoints directly.

Run Ollama, LM Studio, LocalAI, vLLM, or another approved runtime inside the approved boundary.

Keep prompts, transcripts, logs, embeddings, and tool calls inside that boundary.

Limit command execution.

Add repo-level ignore rules.

Test with fake secrets.

Accept that model quality may be lower.

Privacy has a hardware bill.

No free lunch, only cheaper snacks.

Pattern E: restricted repo plus no AI terminal.

Sometimes this is correct.

Use static analysis.

Use local search.

Use manual review.

Use a disconnected machine if needed.

Add AI later when the tool can meet the route requirements.

The mature move is not always adopting the newest agent.

Sometimes the mature move is closing the tab and going outside for seven minutes.

Radical, I know.

The checklist I would actually keep in a repo

Create a file named something like docs/ai-terminal-policy.md.

Keep it short enough that developers will read it.

Use explicit allow and deny lists.

Include examples.

Do not write a constitution unless your company enjoys unread PDFs.

Here is the lightweight version.

  • Approved AI terminal modes:

  • Approved model providers:

  • Approved local endpoints:

  • Repositories allowed for hosted AI:

  • Repositories allowed for BYOK:

  • Repositories requiring local-only inference:

  • Repositories where AI terminal access is blocked:

  • Files always excluded from context:

  • Directories always excluded from context:

  • Secret patterns configured:

  • Command approval policy:

  • MCP or plugin policy:

  • Transcript retention policy:

  • Telemetry policy:

  • Codebase indexing policy:

  • Embedding retention policy:

  • Support log policy:

  • Exception request owner:

  • Last reviewed date:

  • Next review date:

This is not paperwork for paperwork’s sake.

It prevents every developer from re-litigating the same privacy question inside a tool settings screen.

That is where policies go to become confetti.

Common mistakes

Mistake 1: assuming local UI means local data.

The terminal window is local.

The model may not be.

The harness may not be.

The logs may not be.

Mistake 2: assuming BYOK means no retention.

BYOK means your key is used.

Retention depends on the provider account, provider terms, and route.

Mistake 3: ignoring embeddings.

Raw code and embeddings are different artifacts.

Both can matter.

Mistake 4: approving the tool but not the feature.

A terminal may be acceptable with AI disabled.

The same terminal may need separate approval for agents, codebase indexing, cloud agents, sharing, and BYOK.

Mistake 5: forgetting command execution.

A private model can still run a dangerous command.

Privacy review and safety review are siblings.

They borrow each other’s charger and argue anyway.

Mistake 6: treating roadmap discussions as shipped controls.

Roadmap discussions are valuable.

They are not compliance evidence.

Mistake 7: testing on the real repo first.

Use a fake sensitive repo.

Make the tool prove its behavior before it meets the important code.

FAQ

Is local LLM support always safer than hosted AI?

Not always.

Local inference reduces network exposure, but it does not automatically solve command execution, local logging, weak models, unsafe tool calls, or developer mistakes.

A local model with unrestricted shell access can still damage a workspace.

The privacy win is strongest when the prompt, context, transcripts, embeddings, and tool calls all remain inside the approved boundary.

Is BYOK the same as local model support?

No.

BYOK usually means you provide your own API key for a supported hosted provider.

The request can still go to a cloud model provider.

It may improve billing control and provider control, but it is not the same as running a model locally.

Is BYOK the same as Zero Data Retention?

No.

Warp’s BYOK docs explicitly warn that Warp cannot enforce ZDR for requests sent through your own API keys.

You need to verify retention settings and contractual terms in the provider account used by that key.

What is the biggest privacy question for Warp right now?

For local-model-focused teams, the key question is whether future local and arbitrary model support will keep requests truly local with no vendor server transit.

Warp’s official GitHub discussion shows multiple possible architecture paths.

Those paths have different privacy meanings.

Should a team wait for local model support before using AI terminals?

It depends on repo classification.

For public and low-risk repos, hosted AI terminal features may be acceptable under normal policy.

For restricted work repos, waiting for a documented local or approved private route may be the cleaner answer.

Are embeddings less sensitive than source code?

Sometimes, but do not assume that.

Embeddings are derived from source code and can still fall under internal data handling rules.

If a vendor stores embeddings, your checklist should document who owns them, how long they are retained, and how deletion works.

What should developers do before enabling codebase context?

They should confirm which files are included, whether ignored files are respected, where embeddings are generated, whether raw code is stored, and whether embeddings are retained.

They should also test with fake secrets.

Clicking “enable” is easy.

Explaining it later is less fun.

Does open source status solve the privacy problem?

No.

Open source clients help inspection and trust.

But if the agent harness, inference route, indexing service, or control plane still uses vendor infrastructure, the data path still needs review.

Open source is evidence.

It is not a force field.

What is the safest default for restricted repos?

Disable AI terminal features until a local-only or approved private route is documented and tested.

Then allow the smallest useful feature set first.

Start with read-only help.

Add command execution later, if at all.

What is the shortest version of this checklist?

Ask five questions.

What leaves the machine?

Where does inference run?

Who stores prompts, logs, keys, and embeddings?

Can admins enforce the policy?

Can the agent execute commands or read outside the repo?

If those five answers are vague, the setup is not ready for sensitive work.

Sources