Privacy and publication

The checked-in repository should contain public templates and code only. Private credentials, runtime state, client settings, and backups belong outside the checkout.

Public files and private state

Safe public input	Private counterpart
config.yaml with secret references	Rendered runtime config containing a client key
codex/proxy.config.toml with a helper-path placeholder	Your installed profile and global client config
Compose service definitions	OAuth credentials and Tailscale device identity
Documentation with example values	Account emails, real callback URLs, tailnet names, and logs
Website source and design tokens	Local Cloudflare profile and authentication cache

Client backup helpers write outside this repository and set owner-only permissions. The ignore rules exclude personal client directories, local environment files, certificate keys, Cloudflare state, and generated documentation. Ignore rules do not remove files already committed.

Review the current files

Run the publication checks from the repository root:

make code public

This reviews tracked and non-ignored candidate files for personal paths, backup files, and recognizable credential formats. It reports file locations without printing matching values. It is a focused guard, not proof that every possible private fact has been removed.

For broader secret detection, install Gitleaks and scan both the working directory and every Git ref:

gitleaks dir . --redact
gitleaks git --log-opts='--all' --redact

Review binary assets, generated panel HTML, examples, comments, commit messages, branch names, and external hosting settings as well. Search indexes and published pages must use public examples only.

Review Git history before changing visibility

python3 scripts/check-public.py --history

The history check reports private file paths and metadata still reachable from local Git refs. Removing a file in a new commit does not remove its earlier versions. A clean current tree can coexist with unsafe history.

If earlier commits contain private client backups or infrastructure details, keep the repository private until you either:

• Publish a fresh repository from a reviewed clean snapshot, without carrying the old Git objects; or
• Rewrite all affected branches and tags with a tool such as git filter-repo, verify the result, and coordinate replacement of the shared history.

History rewrites change commit IDs and require collaborators to replace old clones. Copies, forks, cached pages, and remote pull-request refs may retain old objects. Changing repository visibility does not revoke credentials. If an actual secret was committed, rotate or revoke it first, even after history cleanup.

Before publication

Review the final snapshot, built site, and all refs you plan to publish. Do not upload secret-scan reports that include raw values; use redacted reports stored privately. Choose a repository license and preserve the required notices for upstream and vendored code. Audit the hosting account and DNS configuration separately from source code.

Do not publish rendered config, provider auth files, Tailscale state, client backups, full operational logs, or screenshots of accounts and callbacks. A successful build or a zero-finding secret scan does not replace this privacy review.