The private-hosts opt-in is accepted in production, and the shipped example turns it on

[beardthelion]

AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS is the one local-only switch that a deployment inherits by copying .env.example. The example ships it as true (.env.example:162), and config.ts accepts it in production without a refusal or a warning:

// server/src/config.ts:497
const allowPrivateHosts =
  optional(environment, "AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS") === "true";

Two hundred and sixty lines above it, the placeholder KEY_ENCRYPTION_KEY gets the treatment this flag does not: throw under NODE_ENV=production, warn everywhere else. The comment on the flag in target.ts says the same thing the key's does, that it is opt-in so a production deployment cannot reach its own network by forgetting to set something, but forgetting is not the path that gets you there. Copying the example is.

What it reaches is wider than browsing. app.ts:646 passes the same value to createAgentRoutes, so it also relaxes checkAgentEndpoint, and in target.ts:257 it is an early return { allowed: true } rather than a relaxation of one rule:

if (options.allowPrivateHosts) {
  return { allowed: true, url: url.toString() };
}

I ran the matrix against main at 146519f:

	result
NODE_ENV=production, flag true	loads, allowPrivateHosts: true
same environment, placeholder KEY_ENCRYPTION_KEY	throws
NODE_ENV=production, flag absent	false, correct
10.0.0.5, 192.168.1.1, 127.0.0.1:5432, [::1]:6379, localhost:3001 with the flag	all permitted, all refused without it
checkAgentEndpoint("http://169.254.1.1/ag-ui") with the flag	permitted, so a signed-in user can register a Bot there
169.254.169.254, metadata.google.internal, [::ffff:169.254.169.254] with the flag	still refused

The metadata floor holds, which is the part that matters most and is worth saying plainly. The default is right too. It is only the opt-in that is ungated.

Two ways to close it, and the choice is yours rather than obvious:

1. Refuse it in production, matching the encryption key. Cleanest, and it means an existing deployment that copied the example fails to start on the upgrade that adds the check, which may be too blunt for a flag that has been shipping this way.
2. Leave the flag alone, warn loudly at boot the way the key does outside production, and comment out or remove the line in .env.example so a copied file no longer arrives with it on.

Happy to send a PR for whichever you prefer.