stack-single 1.3.1

stack-single 1.3.1

A patch for the upgrade from 1.1.x, and for any box that holds a provider key. Upgrading a box with Felyx configured to 1.2.0 or 1.3.0 left the gateway and wardryx restarting in a loop; this release lets that upgrade through, and makes the one change that decides who pays an explicit choice.

Upgrade first

1. If .env has GENARYX_COPILOT_KEY (Felyx's key from before 1.2.0) and you give no key file, the installer now stops before changing anything. Since 1.2.0 the gateway holds the provider key and pays for every agent's calls with it, and refuses an agent that sends its own key. 1.2.0 and 1.3.0 moved Felyx's key there without asking. Choose one:
   • let the gateway hold it: GATEWAY_HOLDS_COPILOT_KEY=1 ./install.sh (the .env value is moved into ./upstream/anthropic/key, never printed), or ANTHROPIC_KEY_FILE=<a file holding the key> ./install.sh;
   • or keep each caller paying with its own key: remove the GENARYX_COPILOT_KEY line from .env. Felyx then has no model until a key file is given.
2. A key file that 1.2.0 or 1.3.0 already wrote is kept, and is now owned by its door's own user. Nothing to do.
3. Then re-run ./install.sh as for 1.3.0; its Upgrade section still applies.

What changed

• Each door's provider key file is owned by the user that door runs as (uid 20010 for the gateway, 20011 for the OpenAI door), mode 0400. 1.2.0 and 1.3.0 wrote it for uid 10001, so the gateway could not read it ("TOKENFUSE_UPSTREAM_KEY_FILE cannot be used: Permission denied") and did not start. Every run now re-owns an existing file to its door.
• Who pays is never changed in silence. Felyx's old key is moved into the gateway's file only on GATEWAY_HOLDS_COPILOT_KEY=1; with neither that nor ANTHROPIC_KEY_FILE, a box holding only that key stops before anything is written and says why.
• wardryx reads its policy archive after the upgrade. The archive directory was re-owned to wardryx's user but the files already in it were not, so wardryx stopped on "permission denied" reading its own archive. The directory is now re-owned with its contents.
• The gate scripts/no-provider-key-outside-the-gateway.sh reads each door's uid from compose.yaml instead of requiring uid 10001, which is how the wrong owner passed every check. Four teeth cases, two scenarios.

Measured

• forge, 2026-10-19, an upgrade from 1.1.35 to 1.2.0: the gateway refused to start on the key file's owner, wardryx restarted on its archive, and the box was rolled back to 1.1.35 from its backups. A fresh 1.3.0 install on a GCP VM given ANTHROPIC_KEY_FILE failed its gateway checks the same way.

Not measured

• The 1.1.35 to 1.3.1 upgrade on forge, which is the next step of the run that found these.