Client-side managed settings
Everything above configures the gateway server. You point developer machines at the gateway separately, on each device, through Claude Code's managed settings. The gateway can't push the login keys itself, because they're what tell the client where the gateway is.
For the CLI, set these keys in the per-OS managed-settings.json. The two login keys route each developer's /login to your gateway:
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
"parentSettingsBehavior": "merge"
}parentSettingsBehavior: "merge" keeps Claude Desktop's delivery of the egress allowlist to its embedded Claude Code sessions working; Deliver policy to Claude Desktop sessions explains the mechanism and where the opt-in must sit.
Deploy the managed-settings.json file to each device, typically via your MDM platform. The file path differs by platform. See where each mechanism stores the policy.
By default, a registry policy on Windows or a managed-preferences plist on macOS replaces the managed-settings.json file rather than merging with it, apart from the exception keys and cross-source checks above. All three keys in this snippet follow the highest-priority-source rule, so fleets that deliver policy through Group Policy or configuration profiles must put all three in that mechanism instead.
For Claude Desktop, set the bootstrapUrl key in Claude Desktop's own managed configuration to <listen.public_url>/user/bootstrap. The sign-in flow and per-group policy then match the CLI's once a policy opts in server-side with a desktop key; without the opt-in, /user/bootstrap returns 404. See Claude Desktop overlay for the server-side half.
forceLoginGatewayUrl, and the "gateway" value of forceLoginMethod, are honored only from a managed source on the machine: managed-settings.json, the macOS plist or Windows HKLM registry, or a policy helper. A developer setting them in their own ~/.claude/settings.json has no effect, and neither does setting them in the gateway payload.