Google Code Wiki Only Works on Public Repos — Here's What to Use for Private Code

Google announced CodeWiki in May 2026, and developers immediately noticed something: the tool is locked to public repositories only.

That makes sense for Google's launch strategy. Public repos are easy to demo, easy to index, and they generate the most viral screenshots. But the announcement quietly raised a question that most developers already know the answer to: your most important codebase is almost certainly private.

That's the repo you actually need documentation for. The one with the authentication layer, the customer data models, the payment flow, the internal APIs. The one that would benefit most from an AI that has read every file and can answer "where do we handle refunds?" without you grepping through 40 microservices.

If CodeWiki can't reach that repo, what can?

Why private-repo documentation is the harder problem

Public repos are the happy path. The source is already exposed. You don't need OAuth scopes, you don't need to explain to your security team why a third-party tool is cloning your codebase. You just paste a URL and watch the summary generate.

Private repos are where everything gets complicated:

• Access control. The tool needs a token or OAuth connection that can read your source. That means a security review.
• Encryption at rest. When the tool clones your code, where does it go? On whose servers? In what jurisdiction?
• AI training policy. Is your source being fed into a foundation model? Even anonymized, large codebases are fingerprintable.
• Team permissions. Who can see the generated docs? Can they edit them? Can external contractors browse them?
• Regulatory compliance. SOC 2, GDPR, HIPAA — the checklist gets longer the moment your code leaves your infrastructure.

CodeWiki solves none of these for private repositories because it never sees them. The limitation isn't a missing feature — it's an architectural boundary Google chose. Public repos are safe for Google to ingest. Private repos require trust infrastructure Google hasn't built.

What developers actually need from a codebase documentation tool

Here's what a real codebase documentation stack looks like in 2026, based on what we've learned from running ShipDocs since launch:

1. Private repo support with secure auth

You should be able to connect GitHub, GitLab, or Bitbucket via OAuth, grant repo-read scope, and have the tool clone your codebase through that authenticated channel. The connection should persist so you can re-import or regenerate docs without going through a connect flow every time.

ShipDocs uses Better-Auth for this — OAuth2 with explicit scopes, account linking, and a token refresh pipeline that stays valid across sessions. You connect once, and your private repos are available in the import picker alongside your public ones.

2. End-to-end encryption

When your private repo's source is cloned, it should be encrypted before it touches persistent storage. Not "encrypted on the disk the database runs on" — encrypted per project, with a unique data-encryption key for each codebase, wrapped by a master key in a KMS-backed vault.

This is exactly what ShipDocs does. Every project's files and generated docs are stored with AES-256-GCM encryption. The database holds ciphertext. The plaintext is decrypted on read, per request, with keys that never leave the vault. This is the same encryption model used by GitHub, Vercel, and Linear.

3. Explicit no-training policy

The most common question we get from engineering teams isn't about pricing — it's "will our code be used to train AI models?"

The answer for ShipDocs is no. We use third-party model providers (OpenRouter, which routes to OpenAI, Anthropic, and others) on zero-retention API endpoints. We pay the providers directly. Your prompts and completions are not retained by them and are not used for training. We don't train any model on customer source files, generated docs, or chat conversations.

CodeWiki hasn't published a no-training policy for private repos because it doesn't handle private repos. But the question is only going to get louder as more teams adopt AI documentation tools.

4. Generated docs that stay current

A documentation tool that produces a static snapshot is useful once. A documentation tool that keeps docs current as your code changes is useful forever.

ShipDocs regenerates docs from the full source tree on demand. In v2, we're adding scheduled auto-regeneration and webhook-based re-indexing on push. That means your docs are never more than a commit behind your codebase.

5. A codebase chat that cites file paths

This is the feature that makes generated documentation actually usable. Instead of reading 40 pages of Markdown to find where userService.create() handles rate limiting, you ask the AI: "where do we rate-limit account creation?" and it answers with the exact file path and line.

ShipDocs' chat is grounded in the structured docs generated from your source, not a generic model. That means it refuses to hallucinate APIs. If the answer isn't in the generated docs, it says so. Every response includes citation tags that link directly to the source file.

Google CodeWiki vs private repo reality

Let's be honest about what CodeWiki is good at and what it isn't.

CodeWiki is a good tool for its target case. It's a browser-based documentation viewer for public repos with AI-generated summaries. If you're maintaining a popular open-source library, CodeWiki might give you a cleaned-up README and a architecture overview.

But most professional development happens in private repos. And for private repos, CodeWiki offers nothing.

What teams are doing instead

We've talked to hundreds of engineering teams since ShipDocs launched. Here's how they're solving private-repo documentation today:

Option 1: Write docs manually. This is the default, and it's why most codebases have documentation debt. Writing docs is slow, correctness is hard to verify, and the docs drift out of date within weeks.

Option 2: Use Cursor or Copilot for "code understanding." These are excellent for editing code, but they're not documentation tools. They don't generate a shareable doc set, they don't produce per-component breakdowns, and the answers you get aren't citation-backed.

Option 3: Paste the repo into ChatGPT / Claude. This works for small repos under a few thousand files. It fails for real codebases because context windows can't hold the entire source tree, and the model invents APIs when it can't find the real ones.

Option 4: ShipDocs. Full documentation generation from private repos, encrypted at rest, with a codebase chat that cites file paths. This is the option teams choose when they need a documentation system, not just a coding assistant.

How ShipDocs handles private repos

Here's the exact flow for importing a private repository into ShipDocs:

1. Connect your Git provider. Click "Connect GitHub" (or GitLab) in the dashboard. OAuth opens in a new tab. You grant repo-read scope.
2. Import from the repo list. Once connected, ShipDocs lists your repositories. Pick one, click Import, and the backend clones it through the authenticated connection.
3. Indexing runs in the background. ShipDocs scans the file tree, detects components from manifest files and directory structure, and generates an Overview doc plus one Markdown doc per component.
4. Docs are encrypted on write. Source files and generated docs are encrypted with AES-256-GCM before they hit the database. The encryption key is unique per project.
5. Browse and chat. Your team sees the generated docs in a navigable sidebar. The AI chat answers questions from the structured docs, with every response citing source file paths.
6. Regenerate anytime. Connect a new branch, push new code, or click Regenerate. Docs refresh from the latest source.

The whole process takes 2–5 minutes for a typical monorepo.

The real reason this matters

Documentation isn't a nice-to-have for internal code — it's a time multiplier. A developer who can find the right doc in 30 seconds makes decisions faster than one who has to open four files and read 200 lines of implementation to understand a pattern.

When you multiply that by team size, the cost of "no docs" becomes enormous:

• Onboarding a new engineer goes from 2–3 weeks of pairing to 2–3 days of reading generated docs plus asking the AI chat.
• Code review velocity increases because reviewers can look up the architecture and conventions without asking the author.
• Refactoring confidence goes up because you can ask the AI "who calls this function?" and get a real answer grounded in the source.

CodeWiki helps with this for public repos. For private repos — where the business value actually lives — you need a tool built for the security requirements and the real workflow.

Try it on your private repo today

ShipDocs has a free tier that includes two private repos, full documentation generation, and 100 chat messages per month. No credit card required.

1. Sign up at shipdocs.sh
2. Connect GitHub or GitLab
3. Pick a private repo and click Import
4. Read the generated docs and try the chat

If you want to see what the output looks like before signing up, browse the OSS showcase — it's generated with the exact same pipeline, just on public repos.

Try ShipDocs: Start free →