Skip to content

Add key-level state ownership to agent manifests #6334

Description

@apurvvkumaria

Problem Statement

Agent manifests can mark whole state files for backup and restore, but cannot declare ownership at the key level. Some agent files mix durable user preferences with NemoClaw-managed routing or security-sensitive settings. Restoring the whole file can overwrite fresh managed configuration or reintroduce credentials and executable behavior; dropping it loses safe preferences.

PR #6332 therefore needs a local, agent-specific allowlist for managed Deep Agents Code config.toml restores. That localized policy should have a clear removal path.

Proposed Design

Extend the agent manifest state-file schema with declarative key-level ownership and restore policy:

  • identify keys owned by NemoClaw, the agent runtime, or the user;
  • support explicit allowlists for user-restorable keys and deny unknown keys by default;
  • define validation constraints for restored values, including type, bounds, and safe enums;
  • let generic backup/restore code merge from the fresh file without agent-specific conditionals;
  • validate manifests at load time and add schema, unit, and migration coverage;
  • migrate Deep Agents Code from its local restore policy, then remove that workaround.

The default for existing manifests must remain whole-file behavior until each mixed-ownership file opts into the new schema.

Alternatives Considered

  • Restore the whole backup file: rejected because mixed files can overwrite managed routing or restore security-sensitive behavior.
  • Drop mixed files entirely: rejected because safe user preferences would be lost.
  • Keep per-agent merge code indefinitely: safe when narrowly allowlisted, but duplicates ownership knowledge outside the manifest and does not scale.

Category

Platform

Checklist

  • I searched existing issues and this is not a duplicate
  • This is a design proposal, not a "please build this" request

Related: #6311, #6332

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: onboardingOnboarding FSM, provider setup, sandbox launch, or first-run flowintegration: dcodeLangChain Deep Code integration behavior

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions