[wmadden-electric]

// prisma.config.ts
composer({
  extensions: [prismaCloud(), nodeBuild()],
  state: prismaState(),
  config: [dotenv(), environmentVariables()],
  secrets: [dotenv(), environmentVariables()],
});

$ prisma deploy --environment staging
✘ [CONFIG.SECRET_AS_PLAIN_VALUE] Root input field input.DATABASE_URL holds the value of the secret "DB_PASSWORD", which an envSecret() in the graph reads.
  Fix: Read the secret with envSecret('DB_PASSWORD') where it is used, or give this plain value text that does not contain the value of "DB_PASSWORD".

prisma deploy runs in two processes. The first is the Prisma CLI: it reads the app's configuration, checks it, and runs preflight. The second runs Alchemy, which creates the resources. Before this PR, the second process ran the config adapters again and had to get the same answer. After it, the configuration is read once, the second process receives what the first one read in a file, and a secret's value never goes into that file.

The decision

• The configuration is read once, in the first process. The config and secrets adapters run there and nowhere else. The second process receives exactly what Load read, in a file only the user can read, and that file is deleted when the command ends.
• The file holds no secrets. Composer refuses to write it when any value in it contains a known secret. The error above is that refusal.
• Composer redacts every known secret in what it prints. A known secret is the value under a name an envSecret() in the graph reads.

Background: two processes, two reads

A Composer app lists its configuration sources in prisma.config.ts. config: lists the adapters for plain values; secrets: lists the adapters for secrets. dotenv() reads .env files and environmentVariables() reads the shell. What the config adapters return, merged, is the app configuration. What the secrets adapters return is the app secrets. These names replace "config pool" and "secrets pool" everywhere.

Before this PR, both processes ran the config adapters. To make the second run return what the first did, environmentVariables() passed the first run's values to the second process in an environment variable, PRISMA_COMPOSER_PARENT_VALUES. Anything else, such as a .env.staging edited during the deploy, could still make the two runs differ. The deploy would then create resources from values nobody had checked.

How the second process gets its configuration now

1. The first process runs the secrets adapters, then the config adapters.

2. It Loads the graph. The root module's input schema checks the app configuration. Load records what it read: each root input field the root's body passes on, with its checked value, and the text of each name an envParam() reads.

3. It writes that record and the graph's node addresses to .prisma-composer/app-configuration-<pid>-<uuid>.json, readable only by the user:

   {"appConfigurationRead":{"rootInput":[{"path":["EMAIL_FROM"],"value":"shop@example.com"}],"configurationKeyText":{}},"nodeAddresses":["shop","shop.email"]}

4. It starts the second process with PRISMA_COMPOSER_APP_CONFIGURATION_FILE naming the file. The second process runs no adapter. It Loads the graph from the record without running the root's schema again.

5. The second process refuses to deploy a graph whose node addresses differ from the file's. That happens when a module body reads process.env, a file or the clock, and builds a different graph the second time.

6. The first process deletes the file when the command ends, whether it succeeds or fails, and when the process exits. A later run deletes a file left by a process that was killed.

prisma dev works the same way. Its second process also needs the secrets the local services use; it receives them in memory, in PRISMA_COMPOSER_NAMED_SECRETS, never in a file. destroy reads only the config list.

Which values are secrets

Load knows the name each envSecret() reads. The value under each of those names, in the app configuration or the app secrets, is a known secret. No other value is. With secrets: [dotenv(), environmentVariables()], a plain .env value or the shell's SHLVL=1 is not a known secret, so it is neither redacted nor refused.

Two checks keep secrets out of the file:

• Load refuses a name read by both envParam() and envSecret(), and a root input field passed on whose name an envSecret() reads. These fail with COMPOSE.GRAPH_INVALID.
• The CLI refuses to write the file when a value in it contains a known secret, with CONFIG.SECRET_AS_PLAIN_VALUE. A secret of 8 characters or more is refused anywhere inside a value, such as a password inside a database URL. A shorter one is refused only when it is the whole value, so a secret dev does not refuse dev@example.com.

Both errors name the field and the secret's name, never its value.

What Composer redacts, and what it does not yet

Composer replaces every known secret with [redacted], at any length, in: every error a command returns, thrown defects and their causes, prisma dev's events, the run report, the deploy reporter and the deployment summary. The redaction that shipped before this PR still applies on top: values of 8 characters or more under credential-looking variable names, and token shapes.

Not redacted, recorded as known limits:

• Alchemy's own output under the CLI. The second process still writes to the terminal directly. Composer redacts its failure cause, not its progress lines. This goes away when Composer runs Alchemy in its own process through Alchemy's programmatic API. A programmatic host that calls spawnAlchemy already gets redacted output.
• Errors before Load. Until Load has run, Composer does not know which names are secrets. An adapter that throws, or a root schema failure that echoes a value, is redacted only by the credential-looking rule.
• Step labels and the Deployed <app> line. They carry node addresses and the app name, which are not redacted.
• destroy. It reads no secrets, so it cannot refuse a value that only the secrets list returns.

S11: dotenv() reads through dotenv-flow

dotenv() now reads its files through dotenv-flow 4.1.0, in the same order as before: .env, .env.local, .env.<environment>, .env.<environment>.local. It never reads .env.defaults. It now skips .env.local for the environment test, as dotenv-flow does.

Breaking changes

// before
Load(root, { configPool: { EMAIL_FROM: 'a@example.com' } });
paramSource(payload, { label: "myParam('X')", poolKey: 'X' });

// after
Load(root, { configuration: { EMAIL_FROM: 'a@example.com' } });
paramSource(payload, { label: "myParam('X')", configurationKey: 'X' });

• Renames. LoadOptions.configPool is configuration. paramSource()'s poolKey is configurationKey. The types ConfigPool, SecretsPool and ConfigPools are AppConfiguration and AppSecrets. LoadOptions is now a union of FirstProcessLoadOptions and SecondProcessLoadOptions, so interface X extends LoadOptions stops compiling; extend one of the two.

• Extension authors. A preflight step and a local attachment's serve step receive configuration and secrets in place of pools. localTargetProviders() takes configurationKeyText and namedSecrets. @prisma/composer/internal/pools is gone; it was not public API.

• import 'dotenv/config'. If prisma.config.ts has it and you adopt dotenv(), remove it. Otherwise .env's values enter the process environment, environmentVariables() returns them last, and they override .env.<environment>.

  // before
  import 'dotenv/config';
  composer({ /* … */ config: [environmentVariables()] });
  
  // after
  composer({ /* … */ config: [dotenv(), environmentVariables()] });

• dotenv() skips .env.local for the environment test.

• A module body that builds a different graph in the second process fails the deploy, naming the addresses.

• A root input field passed on must hold JSON data: text, a finite number, a boolean, null, or arrays and plain objects of these. A Date from a transform fails the Load.

• A name read by both envParam() and envSecret() fails the Load. So does a root input field passed on whose name an envSecret() reads.

• The file check, CONFIG.SECRET_AS_PLAIN_VALUE, as above.

• A non-text envParam() value in a service's input or params fails at Load, before anything is created. It used to fail later.

• Adapter order. The secrets adapters run before the config adapters, so a broken secrets adapter is reported first.

• Redaction of the lists. Only values under names an envSecret() reads are known secrets. Before, every value a written secrets list returned was redacted. A known secret is redacted at any length: a one-character secret blanks that character in the output.

• environmentVariables() returns the whole process environment, PRISMA_COMPOSER_ variables included.

• Versions. @prisma/composer and @prisma/composer-cli must be the same version: the generated stack file imports @prisma/composer/internal/app-configuration-file.

Testing

• Core tests for Load in each process: the record it writes, the second process reading it without the root's schema, a root field missing from the record, every new Load error, and the node-address check.
• CLI tests for the adapters' order, the file's contents, mode and deletion (including a file left by a killed process), the file check at both secret lengths, redaction in every place listed above, and the secrets prisma dev hands its second process.
• test/integration/test/local-dev.integration.ts and local-dev-store.integration.ts drive prisma dev's second process with the file and the named secrets.
• Manual QA against Prisma Cloud, six steps, all passing: .drive/projects/module-input/slices/s11-s13-configuration-read-once/qa.md.

Documentation

• The decision records for secrets (ADR-0029), env-sourced params (ADR-0032), errors (ADR-0044), the composer config section (ADR-0049), dev secrets (ADR-0058) and environment values (ADR-0062) are each rewritten as one current record.
• The glossary, deploy-cli.md, config-params.md, local-dev.md, the building-an-app, running-locally and deploying guides, and the core-concepts agent skill match the code.

Alternatives considered

• Keep running the adapters in the second process. Both runs must then agree, and nothing makes them. A .env file edited mid-deploy, or an adapter that reads a remote store, could deploy values nobody checked.
• Pass the whole app configuration to the second process. It would carry every variable of the shell, and any secret in the config list, into a file. The record holds only what Load read.
• Treat every value in the secrets list as a secret. With the recommended secrets: [dotenv(), environmentVariables()], every shell variable would be a secret, including SHLVL=1. Redacting 1 everywhere makes output unreadable, and the file check would refuse ordinary values.
• Redact Alchemy's output through a new engine option (feat(engine): ctx.spawn can pass a child's output through a transform before printing it prisma-cli#383). Dropped: running Alchemy in Composer's own process removes the second process, and the option with it.

Spec: .drive/projects/module-input/slices/s11-s13-configuration-read-once/spec.md. Design: .drive/projects/module-input/design.md, sections 8 and 9.

Agent: hipparchus-99

🤖 Generated with Claude Code

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 2fcb95c2-e747-4e5d-81e1-dcd685a59457

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[prisma-gizmo]

✅ Gizmo reviewed d412ca8 — posted 1 inline comment(s) this pass.

Open findings: 🟡 1 minor

Change walkthrough

This delta makes the app-configuration-file tests tolerate Windows, where Node cannot observe POSIX permission bits: the 0o600 mode assertions become conditional on process.platform !== 'win32'.

The pull request's second-process handover writes the deploy's configuration record with writeFileSync(..., { mode: 0o600 }) in app-configuration-file.ts:188. On Windows that mode is unrepresentable — Node only maps 0o444 to the read-only attribute — so statSync().mode & 0o777 never reports 0o600 there, and ci.yml runs this package's tests on windows-latest. The delta adapts three assertions to that reality:

• app-configuration-file.test.ts:103 and line 123 guard the mode expectation with an inline if, so the JSON-content and file-replacement assertions still run on every platform; only the mode check is POSIX-only.
• operations.test.ts:3980 turns the expected mode in the deploy handover test into process.platform === 'win32' ? expect.any(Number) : 0o600. This is the right shape for that test, since the mode sits inside a toEqual against the object the alchemy hook observed; the record's JSON, the node-address match, and the post-deploy deletion assertions are untouched.

The behavior being tested is unchanged — this is a test-only delta, and no production code moved. The file's owner-only guarantee remains asserted on macOS and Linux, which matches where the guarantee is observable; on Windows the file's protection rests on default ACLs, which the mode API cannot express.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@419

npm i https://pkg.pr.new/@prisma/composer-cli@419

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@419

commit: d412ca8

[prisma-gizmo]

New findings: 🔴 6 critical · trace

[prisma-gizmo]

No Gizmo finding is open and the head commit has been reviewed. Approving.

[prisma-gizmo]

New findings: 🟡 1 minor · trace

[prisma-gizmo]

🟡 Minor · consistency — Inline if (process.platform !== 'win32') guard around expect contradicts the package's test.skipIf idiom and silently drops the mode assertion on Windows

Every other platform-conditional test in this package uses test.skipIf(process.platform === 'win32')(...) or describe.skipIf(...) (e.g. control.test.ts:40, operations.test.ts:1795, run-alchemy.test.ts:413), which shows up as a skip in test output. An inline if around expect instead reports the test as passing on Windows with the owner-only-mode guarantee unverified, and both affected test titles ('…readable only by its owner', 'a file already there is replaced, and gets mode 0600') still state the 0600 claim unconditionally. Same guard pattern repeated at line 123 and echoed by the 'mode 0600' title in operations.test.ts:3962.

Recommended fix

Extract the mode check into its own test.skipIf(process.platform === 'win32')('the file is readable only by its owner', ...) matching the package idiom, or qualify the titles (e.g. 'gets mode 0600 (POSIX)') so the skipped coverage is visible in test names.