Skip to main content
See Instructions and Playbooks to configure Charlie’s behavior.

​
Environment variables

Environment variables allow Charlie to run dev servers, tests, and other tools. They are set from the dashboard and are injected into the Devbox (VM) Charlie operates in at runtime.
Adding the environment variables required for local development of the repo will substantially improve Charlie’s performance.
Common variables you might add:
  • Non-production tokens, secrets, config, for local development of the repo (e.g. the contents of .env files).
  • E2E/dev server knobs (e.g., PLAYWRIGHT_*, CYPRESS_*, framework‑specific NEXT_PUBLIC_*, VITE_*).
  • NPM_TOKEN (or NPM_AUTH_TOKEN) – Install private NPM packages.
  • Remote cache or CI tokens used by your build (e.g., TURBO_TOKEN/TURBO_TEAM if you use Turborepo remote caching).
Adding TURBO_TOKEN & TURBO_TEAM will make Charlie faster because he frequently runs Turbo tasks when available.

​
How to add environment variables

Environment variables are added from the dashboard and are scoped to a single repository.
  1. Navigate to the dashboard.
  2. Choose the organization the repo belongs to (you will automatically be redirected if you only have one).
  3. Click the “ENV VARS” link for the repo you want to add variables to.
  4. Enter the name and value for each variable (values are encrypted at rest).

​
Repository configuration

Location: .charlie/config.yml on the default branch. Changes take effect after merging to the default branch. If the file is missing or invalid, safe defaults are used.

​
Schema and behavior

  • checkCommands: { fix?, lint?, types?, test? } – Shell commands Charlie can run inside the Devbox.
    • All commands run from the repository root inside the Devbox.
    • fix is run after Charlie edits code (format/lint autofix, codegen, etc.).
    • types enables a TypeScript verification step when provided.
    • lint runs your linters (for example, ESLint).
    • test runs your unit tests (not E2E or integration tests).
  • beta – Experimental feature toggles:
    • canApprovePullRequests (default: false) – Allow Charlie to post an “Approve” review when appropriate (never for Charlie‑authored PRs).
    • proactive – Opt‑in list of playbooks to execute automatically each day. Each item is an object with a single playbook field pointing to a file path in your repo (additional fields are not supported in beta). See Proactive Behaviors for details.

​
Example config

checkCommands:
  fix: bun run fix
  lint: bun run lint
  types: bun run typecheck
  test: bun run test
beta:
  canApprovePullRequests: false
  proactive:
    - playbook: ".charlie/playbooks/sentry-triage.md"
    - playbook: ".charlie/playbooks/auto-update-docs-site.md"
    - playbook: ".charlie/playbooks/dead-code-cleanup.md"
    - playbook: ".charlie/playbooks/upgrade-outdated-dependency.md"
Monorepo tip: many teams expose aggregate scripts like fix:all, lint:all, typecheck:all, and test:all that fan out with a task runner (for example, Turborepo). It’s a good idea for your lint step to also enforce a Prettier check (and optionally an unused code/deps check like Knip) so formatting and hygiene failures are caught during verification.

​
Example (monorepo aggregates)

checkCommands:
  fix: bun run fix:all       # e.g., ESLint --fix + Prettier write
  lint: bun run lint:all     # e.g., ESLint + Prettier check + Knip
  types: bun run typecheck:all
  test: bun run test:all

​
Additional notes

  • Invalid or misshaped values are ignored per‑field and replaced with defaults (other valid keys are preserved).

​
FAQs

​
“We merged config changes but nothing changed.”

Config is read from the default branch; ensure the file lives at .charlie/config.yml and changes are merged to default.

​
“Charlie approved a PR.”

That only happens if beta.canApprovePullRequests is true, the review found no significant issues, and the PR isn’t authored by Charlie.