When managing multiple Google Apps Script projects across different client environments (e.g., within 03_clients/), running clasp login locally presents severe cross-contamination risks. Google has also deprecated the OOB (Out-Of-Band) --no-localhost authentication flow, making remote server authentication fail with ERR_CONNECTION_REFUSED unless complex SSH port-forwarding is used.
Solution: 1Password Seed Injection + Symlinking
To maintain strict “Identity Isolation” per client while ensuring seamless CLI deployments from a remote Debian Engine, we use a master-key symlink architecture.
1. Generating & Vaulting the Seed (The Glass)
On a local machine with a browser, run npx @google/clasp login for the specific client identity (e.g., [email protected]).
Copy the contents of the generated ~/.clasprc.json.
Store this JSON in 1Password as a Secure Note (e.g., “Clasp Auth - [Client]“).
2. Injecting the Master Key (The Engine)
On the remote server, use the 1Password CLI (op) to inject the Secure Note directly into the root of the client’s workspace.
(Note: The global server fallback key is stored at ~/.clasprc.json for non-client operations).
3. Project-Level Symlinking
Because clasp actively overwrites the .clasprc.json file whenever it refreshes an access token, copying the file into sub-projects causes auth loops and desyncs.
Instead, inside every Apps Script sub-project, create a symlink pointing back to the client’s Master Key:
cd ~/projects/03_clients/[client]/[sub-project]ln -s ../.clasprc.json .clasprc.json
Benefits
Zero Cross-Contamination: Deploying from 03_clients/client_A/script guarantees use of Client A’s identity, while 03_clients/client_B/script guarantees Client B’s.
No Browser Needed: Bypasses all localhost browser redirect issues on the remote server.
Stateful Refreshes: Because of the symlink, when clasp refreshes the token, it updates the Master Key file, instantly re-authenticating all other symlinked sub-projects for that client.