Avoid printing partial Render API key during setup-deploy check

Open Beginner friendly
#1,078 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
68/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Tech stack
shell

Research direction

Open setup-deploy/SKILL.md at line 851 and review the setup-deploy instructions around the Render API key check. Replace the partial-key output with the suggested presence check, then verify that the instruction reports whether the variable is set without printing any key bytes.

Written by the indexing model from the issue text.

Description

File: setup-deploy/SKILL.md line 851

Current instruction:

Check for Render API key: `echo $RENDER_API_KEY | head -c 4` (don't expose the full key)

The inline comment shows the intent, but the instruction still prints the first 4 characters of the key into terminal scrollback, screen recordings, and screenshots. A presence check would serve the same "is the key available?" purpose without writing any key bytes to stdout.

Suggested replacement

if [ -n "${RENDER_API_KEY:-}" ]; then
  echo "RENDER_API_KEY: set"
else
  echo "RENDER_API_KEY: not set"
fi

If a stable fingerprint for cross-run correlation is useful:

if [ -n "${RENDER_API_KEY:-}" ]; then
  printf 'RENDER_API_KEY: sha256:'
  printf '%s' "$RENDER_API_KEY" | shasum -a 256 | cut -c1-8
fi

(The :- guards against set -u if the var is unset; shasum is macOS-native, sha256sum on Linux.)

Why this is worth the cheap swap

Partial-secret printing tends to get normalized once it ships in a skill doc — downstream users copy the pattern. A four-character prefix may be low severity in isolation, but:

  • It still leaks into scrollback, logs, screen shares, and IDE terminal captures
  • Many providers use fixed prefixes (rnd_, sk-, etc.), so the leaked chars are often the non-entropy part anyway
  • The presence check achieves the same intent with zero byte leakage

Low-cost hardening, not a severe vuln — happy to send a PR if useful.


Found during a security audit of a Claude Code + Codex + MCP stack. Same class of finding was fixed in our own setup scripts after an adversarial review flagged it.

Dominant language
TypeScript
Stars
134k
Forks
19.9k
Avg merge
20h 59m
Merged PRs (30d)
21

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from garrytan/gstack

All issues in garrytan/gstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.