Introduction

CODI’s behavior is driven by its configuration file, codi.toml. Here you can enable or disable agents, adjust security and retry settings, and register custom hooks. In team environments, assign roles to enforce least-privilege access across code review, audit approvals, and deployments.

1. codi.toml Schema

• Project Section

  [project]
  
  

  Defines basic metadata.

• Agents Section

  [agents]
  
  

  Globally enable or disable core agents.

• Agent-Specific Settings

  [audit]
  linters            = ["slither", "custom-lint"]
  severity_threshold = "medium"
  retries            = 2
  
  [deploy]
  
  

  Tune individual agent behavior.

• Hooks & Extensions

  [scaffold]
  pre_hook  = "scripts/pre_scaffold.sh"
  post_hook = "scripts/post_scaffold.sh"
  
  [plugins]
  paths = ["./my-agent-plugin"]

  Register shell hooks and plugin paths.

2. Roles & Permissions Model

• Developer

  • Can run scaffold, test, and view logs.

  • Cannot approve audits or deploy to production.

• Reviewer

  • All Developer permissions plus can review and sign off audit-report.

  • Marks findings as resolved.

• Deployer

  • Can execute deploy-agent to publish to configured networks.

  • Can rollback to last snapshot.

• Assigning Roles
  Roles are assigned via the UI’s Team Settings or through GitHub org sync (coming soon).

3. Enforcement & Auditing

• Permission Checks
  Every agent checks the caller’s role before execution. Unauthorized commands return HTTP 403 or CLI error.

• Audit Logs
  All actions (init, audit, test, deploy) are recorded with user ID, timestamp, and context node ID in the MCP log store.

Conclusion

codi.toml and the roles model give you fine‑grained control over CODI’s behavior and team workflows. Configure agents to suit your project, and leverage roles to maintain security and auditability across your development lifecycle.