cli.config_generate_refused

A new key would be written where a person could read it, by jadpo config generate, or --generate would replace a key already set.

Area 14, Tooling; not declinable; the next step is usually the human's.

Why Jadpo refuses it

Nobody needs to see a key, and losing or leaking one can't be undone. So jadpo config generate writes one only into a pipe, never to a terminal or inside a JSON document, where it would stay in scrollback or a coding agent's context. And jadpo config set <field> --generate won't replace a key already set: everything the old key sealed would be unreadable, for good.

What it looks like

A project that seals with field_encryption_key, whose key is already in .env.local:

jadpo config set field_encryption_key --generatejadpo config set field_encryption_key --generate

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides whether what the key sealed is kept.

At a terminal, jadpo config generate is refused the same way:

jadpo config generate field_encryption_key

How to fix it

If you are rotating the key, move its value to FIELD_ENCRYPTION_KEY_PREVIOUS in .env.local, remove FIELD_ENCRYPTION_KEY, and run this again:

jadpo config set field_encryption_key --generate

The app then reads both until nothing needs the old one (Rotating the key).

If you want a key for somewhere else, pipe it there:

jadpo config generate field_encryption_key | wrangler secret put FIELD_ENCRYPTION_KEY

The key goes straight into your secret manager, and nothing on this machine holds it.

Related

• Setting a value: jadpo config set
• What can't be undone