Proposal: Separate API keys from project config to prevent accidental exposure

[willeastcott]

Problem

There are two vectors for accidental API key exposure:

1. Git commits: pcconfig.json lives in the project directory and is not gitignored. When it contains PLAYCANVAS_API_KEY, users can accidentally commit their key to public repos. This has already happened to users (see Security Feature Request - Disallow Uploading of pcconfig.json with API Key  #24).

2. PlayCanvas upload: pcsync push and pcsync watch sync files from the target directory to PlayCanvas. If pcconfig.json is in the target directory, it can be uploaded to the cloud project -- it is not excluded by the default BAD_FILE_REG pattern ^\.|~$. This makes the API key visible to anyone with access to the project.

The root cause is that pcsync init writes the API key directly into pcconfig.json, and the README examples show putting it there too.

Proposed Solution

Core principle: Separate secrets (API key) from project configuration (project ID, branch ID, target dir).

The config loading system already supports a two-file model:

• ~/.pcconfig (home directory) -- loaded first, already gitignored in the repo
• pcconfig.json (project directory) -- project-specific, safe to commit

The change is to enforce that PLAYCANVAS_API_KEY belongs in ~/.pcconfig (or env vars / CLI flag), never in pcconfig.json.

1. Update pcsync init to separate API key from project config

• Still prompt for the API key, but write it to ~/.pcconfig instead of pcconfig.json
• If ~/.pcconfig already exists, merge the API key into it (preserve other fields)
• Write only non-secret fields to pcconfig.json (project ID, branch ID, target dir, etc.)
• Print clear guidance:
  API key saved to ~/.pcconfig (keep this private) Project config saved to pcconfig.json (safe to commit)

2. Warn when API key is found in pcconfig.json

When loading config, if pcconfig.json contains PLAYCANVAS_API_KEY, print a warning:

WARNING: PLAYCANVAS_API_KEY found in pcconfig.json. This file is often committed to version control and could expose your key. Run 'pcsync init' to migrate your API key to ~/.pcconfig, or set the PLAYCANVAS_API_KEY environment variable.

The tool still works (no breaking change), but the warning is clear and actionable.

3. Always exclude pcconfig.json and .pcconfig from sync operations

Add a hardcoded check in the sync pipeline (push/watch/diff) that prevents pcconfig.json and .pcconfig from being uploaded to PlayCanvas, regardless of BAD_FILE_REG settings. This is a safety net that directly addresses #24.

4. Interactive API key prompt when missing

If no API key is found from any source after config loading, instead of immediately throwing an error, prompt the user interactively:

No API key found. Enter your PlayCanvas API key: ___ Save to ~/.pcconfig for future use? [Y/n]

If they choose to save, write/merge it into ~/.pcconfig. Skip the prompt in non-interactive environments (check process.stdin.isTTY) and throw the existing error instead.

5. Update README

• Update sample configs to show pcconfig.json without PLAYCANVAS_API_KEY
• Add a Security section explaining where to store the API key
• Update the Getting Started flow to reflect the new init behavior

Backward Compatibility

• No breaking changes: Existing pcconfig.json files with API keys continue to work; the key is still read from there in the config hierarchy
• Additive warning: Users see a clear warning with migration instructions
• Gradual migration: pcsync init becomes the migration path -- running it on an existing project moves the key to ~/.pcconfig

Supersedes

This proposal is a comprehensive solution that supersedes #24 by addressing the root cause rather than just the upload vector.

[Christopher-Hayes]

Putting the API key in ~/.pcconfig seems like a fine solution. Unlikely to make it into git. Reduces breakage.

This is essentially what rclone does. On Linux, it uses the ~/.config/ directory, and puts your provider auth creds in a config file in there.

The one other option I see is to attempt to leverage .env files/session vars as that's how most git projects use secrets. That has the advantage of allowing devs to choose how they manage their secrets, but it does mean more work for the dev. ~/.pcconfig seems good, no reason to over-complicate with an .env.