[Bug]: confirmation_policy, security_analyzer, and secrets mutations not persisted to meta.json

[BSmick6]

Bug Description

When set_confirmation_policy, set_security_analyzer, or update_secrets are called via the API, the change is written to ConversationState/base_state.json but StoredConversation/meta.json is never updated. On next startup, event_service.py lines 1090–1102 read all three fields from stored to initialize the conversation, so the changes are silently reverted after eviction or server restart.

Expected Behavior

API mutations to confirmation_policy, security_analyzer, and secrets persist across conversation eviction and server restart.

Actual Behavior

Changes are lost; the conversation reverts to the values set at creation time. This can be verified by running the existing test suite and adding a test that:

1. Creates a conversation
2. Calls the mutation endpoint (e.g. set_confirmation_policy)
3. Simulates eviction by removing the event service from _event_services
4. Reloads the conversation via _get_or_load_event_service
5. Asserts the updated value is still present

pytest tests/agent_server/ -k "confirmation_policy or security_analyzer or secrets"

The relevant code paths are:

• EventService.set_confirmation_policy (line 1668) — only calls self._conversation.set_confirmation_policy(policy); no self.stored update, no save_meta()
• EventService.set_security_analyzer (line 1677) — same pattern
• EventService.update_secrets (line 1658) — only calls self._conversation.update_secrets(secrets); no self.stored update, no save_meta()

On startup, event_service.py reads all three from stored:

# line 1090
secrets=self.stored.secrets,
# line 1101
conversation.set_confirmation_policy(self.stored.confirmation_policy)
# line 1102
conversation.set_security_analyzer(self.stored.security_analyzer)

Compare to EventService.apply_resume_secrets (lines 352–355) which correctly updates self.stored and calls await self.save_meta() after mutating state.

Acceptance Criteria

• set_confirmation_policy updates self.stored.confirmation_policy and calls save_meta() after mutating ConversationState
• set_security_analyzer updates self.stored.security_analyzer and calls save_meta() after mutating ConversationState
• update_secrets updates self.stored.secrets and calls save_meta() after mutating ConversationState
• Tests verify each change survives a simulated eviction/reload

Additional Context

Discovered while reviewing #4617. tags is currently the only field where API mutations correctly write back to stored and persist to meta.json. Discussed in #proj-agent-server.

[github-actions]

✅ ready-for-dev label applied

This issue meets the readiness criteria and is ready for contribution.
A contributor can now open a PR that links this issue (Fixes #<number>).

This is an automated check — no AI was used to generate this comment.

[enyst]

written to ConversationState/base_state.json but StoredConversation/meta.json is never updated. On next startup, event_service.py lines 1090–1102 read all three fields from stored to initialize the conversation, so the changes are silently reverted after eviction or server restart.

The intended design is that, if they’re part of ConversationState, they should be written only to base_state.json, rather than duplicated in meta.json. event_service should read them from there. If that seems unwieldy, maybe we can investigate why 🤔

[BSmick6]

The intended design is that, if they’re part of ConversationState, they should be written only to base_state.json, rather than duplicated in meta.json. event_service should read them from there. If that seems unwieldy, maybe we can investigate why 🤔

I don't think it'll be too bad. I can look into it when I start working on this but I think those lines in the startup function should be it. I can lyk if there's more to it than that though.

edit: i was wrong lol

edit2: actually not too bad

edit3: secrets might be the one tricky part. I'll post another comment with more details.

[BSmick6]

Following up on the secrets complication I mentioned — it ended up not being bad either. The main thing was that secrets couldn't just be removed from StoredConversation cleanly because there was a CODEX credential injection site in conversation_service that was temporarily mutating stored.secrets just before EventService.start(). With secrets moved to an explicit field on EventService, that injection now passes the secret as a constructor argument instead, which is actually cleaner — no more try/finally to restore the original stored after the call.

The other small wrinkle was that ConversationState uses a SecretRegistry object internally (rather than a plain secrets dict), so update_secrets couldn't just reassign a field to trigger the autosave — we needed to copy the registry, update the copy, then reassign. Everything else followed the same pattern as #4440.