For Support

This page is written for whoever fields questions from engineers about why their PR sandbox came up with unexpected settings — not for customer support, since this PR has no customer-facing surface.

Questions you'll likely get

"My sandbox didn't turn on WhatsApp even though I didn't touch the Sandbox block — why?" Check whether a SANDBOX_ALL_WHATSAPP or SANDBOX_<branch>_WHATSAPP variable/secret exists on the sandbox GitHub Environment and what it's set to. Any value that isn't 1/true/yes/on (case-insensitive) parses as off — truthy() at .github/workflows/sandbox.yml:149. If nothing is set at all, the toggle falls through to whatever the built-in compose defaults do, since nothing in this layering step sets it.

"I set whatsapp: true in my PR body but it's still off." The PR-body layer always wins on keys it sets (.github/workflows/sandbox.yml:174-175), so if it's still off, first check the PR body's heading actually matches — the extraction looks for a ## heading whose text contains "sandbox" (case-insensitive), immediately followed by a fenced code block (sandbox.yml:118-124). A heading that doesn't literally contain "sandbox," or a settings block that isn't the first fenced block after that heading, won't be picked up. Second, check the Action run's log group 🧪 sandbox settings (layered: env vars → secrets → PR inline) — it prints the final resolved toggles, so you can see directly whether the PR value was applied.

"I wrote SOME_KEY: secret:MY_TOKEN in my PR body and the deploy failed." The step fails the whole job if MY_TOKEN doesn't exist as a secret visible to the sandbox environment (repo/org secret, or the environment's own), or if the name (case-insensitively) is github_token — that one is rejected outright, it can never be injected (.github/workflows/sandbox.yml:164-173). Check the Action run's error message; it names the missing secret, never a value.

"How do I tell what settings a running sandbox actually has, after the fact?" The PR comment left by the deploy job includes a "Settings" row (sourced from SETTINGS_SUMMARY, produced downstream by the sandbox info command, not by this PR's step) — that's the human-readable summary. For the exact layered inputs, the Action run's own log group is the source of truth: it lists resolved toggles and env key names (never values).

"Can I see what secret value actually got injected?" No, by design. The step's own log output never prints env values, only key names (.github/workflows/sandbox.yml:182-186), and GitHub additionally masks any string in the log that matches a known secret's value. If you need to confirm a value made it into the running sandbox, use the sandbox's own Terminal access to inspect the container's environment directly — see Secrets and safety guardrails for why that's an accepted, documented boundary rather than a bug.

Where to look, in order

1. The PR's ## 🧪 Sandbox block (if any) — remember it wins every

conflict.

1. The sandbox GitHub Environment's variables/secrets, scoped to

SANDBOX_ALL_* and SANDBOX_<SANITIZED_BRANCH>_* (see Glossary for how branch names sanitize).

1. The deploy job's 🧪 sandbox settings log group — the actual resolved

output, regardless of which layer produced it.