fix(gastown): Town model config reverts to kilo/free after container restart

[jrf0110]

Bug

After configuring a town to use anthropic/claude-opus-4.6 for all agent models (via the per-role model settings), the mayor reverts to kilo/auto-free after a container restart. Changing the model via the settings page has no effect — the mayor continues using kilo/auto-free.

Observed Behavior

1. Created a new org town
2. Configured all models to anthropic/claude-opus-4.6 in town settings
3. Mayor initially used Opus 4.6 correctly
4. Container restarted (deploy, eviction, or manual restart)
5. Mayor came back using kilo/auto-free instead of the configured model
6. Changing the model in settings did not fix it — the mayor kept using kilo/auto-free
7. Had to manually use /models in the mayor CLI to select Opus 4.6

Likely Cause

The model is baked into KILO_CONFIG_CONTENT at agent dispatch time (container/src/agent-runner.ts:buildKiloConfigContent). When the container restarts and the mayor is re-dispatched, the model is resolved from townConfig.default_model (or townConfig.role_models.mayor). If the town config read at dispatch time returns a stale or default value, the model defaults to kilo/auto-free.

This may be related to #1614 (settings save hangs for 15s — the updateMayorModel call may not be completing), #1438 (model change doesn't update running session), or #1756 (org billing context lost after model change — the same config propagation gap).

The settings page change not taking effect suggests syncConfigToContainer or updateMayorModel is failing silently, or the container is reading a cached config rather than the latest from the TownDO.

Files

• src/dos/Town.do.ts — ensureMayor, sendMayorMessage (model resolution at dispatch)
• src/dos/town/config.ts — buildContainerConfig (what gets synced)
• container/src/agent-runner.ts — buildKiloConfigContent (model injection)
• src/trpc/router.ts — updateTownConfig mutation (model change propagation)

Acceptance Criteria

• Model config persists across container restarts
• Changing model in settings takes effect on next mayor session
• Per-role model overrides (role_models.mayor) respected at dispatch time

[jrf0110]

Root Cause Found

The model itself IS dispatched correctly on container restart. The bug manifests on subsequent model changes (via the settings UI) after a restart.

The chain:

1. Container restarts → all in-memory state wiped
2. ensureMayor re-dispatches mayor → startAgentInContainer passes correct model + organizationId → buildKiloConfigContent builds correct KILO_CONFIG_CONTENT → mayor starts with correct model ✅
3. But: ensureSDKServer() (process-manager.ts:216-224) temporarily sets process.env.KILO_CONFIG_CONTENT for the createKilo() call, then restores it to undefined after the SDK starts
4. User changes model in settings → updateMayorModel → PATCH /agents/:agentId/model
5. updateAgentModel() (process-manager.ts:808) calls extractOrganizationId() which reads process.env.KILO_CONFIG_CONTENT → undefined → organizationId = undefined
6. buildKiloConfigContent(token, model, smallModel, undefined) — new config is built without kilocodeOrganizationId
7. The Kilo gateway sees a request without team context → falls back to kilo/auto-free

The specific code gap:

process-manager.ts:ensureSDKServer() at lines 216-224 snapshots process.env, sets KILO_CONFIG_CONTENT, starts the SDK, then restores the snapshot (which deletes KILO_CONFIG_CONTENT). This means extractOrganizationId() can never find the org ID after initial startup.

Fix:

Store organizationId on the ManagedAgent object when first set during buildAgentEnv(). Read it from there in updateAgentModel() instead of from process.env.KILO_CONFIG_CONTENT.

Or: don't restore KILO_CONFIG_CONTENT to undefined — keep it in process.env permanently.

Files:

• container/src/process-manager.ts:216-224 — env snapshot/restore deletes KILO_CONFIG_CONTENT
• container/src/process-manager.ts:752-764 — extractOrganizationId() reads from process.env
• container/src/process-manager.ts:808 — updateAgentModel() loses org context

[jrf0110]

PR #1828 (constituent PR #1759) fixes token propagation — KILOCODE_TOKEN now syncs to running containers via LIVE_ENV_KEYS and CONFIG_ENV_MAP. This may partially address the model revert, but the core issue (organizationId lost from process.env.KILO_CONFIG_CONTENT after ensureSDKServer restores the env snapshot) may still be present. Needs verification after deploy.

[jrf0110]

Should be good now