codex - 💡(How to fix) Fix Support organization-scoped agents with isolated memory, skills, and project context

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Codex currently feels centered around one primary agent experience. As users connect more repositories, SSH hosts, teams, and long-running projects, a single agent can accumulate too much unrelated context over time.

It would be helpful to support multiple scoped agents, organized under higher-level organizations or companies, with separate memory, files, skills, and project context.

Root Cause

Codex currently feels centered around one primary agent experience. As users connect more repositories, SSH hosts, teams, and long-running projects, a single agent can accumulate too much unrelated context over time.

It would be helpful to support multiple scoped agents, organized under higher-level organizations or companies, with separate memory, files, skills, and project context.

Code Example

Organization / Company
  -> Agent
      -> Projects / repositories / SSH hosts / memories / skills
RAW_BUFFERClick to expand / collapse

Summary

Codex currently feels centered around one primary agent experience. As users connect more repositories, SSH hosts, teams, and long-running projects, a single agent can accumulate too much unrelated context over time.

It would be helpful to support multiple scoped agents, organized under higher-level organizations or companies, with separate memory, files, skills, and project context.

Problem

A single long-lived agent can become overloaded when it is used across many unrelated areas of work. Context from one project, company, server, or workflow may become irrelevant or even harmful when working on another.

For example, a user may have:

  1. Multiple organizations, companies, or clients.
  2. Several projects per organization.
  3. Different coding standards, deployment workflows, credentials, and operational assumptions.
  4. Specialized agents for backend, frontend, infrastructure, QA, data, or support.
  5. Shared organization-level knowledge that should not leak into unrelated organizations.

Without stronger separation, the agent has to remember too much and the user has to keep correcting scope manually.

Feature request

Add first-class support for a hierarchy such as:

Organization / Company
  -> Agent
      -> Projects / repositories / SSH hosts / memories / skills

Each organization could have shared context, while each agent inside that organization could have its own specialized memory, skills, files, and working scope.

Suggested design

  • Allow users to create multiple organizations or workspaces.
  • Allow each organization to contain multiple agents.
  • Give each agent isolated memory, skills, files, preferences, and project access.
  • Support optional shared organization-level memory for common standards and workflows.
  • Let agents communicate or delegate tasks to each other when explicitly allowed.
  • Make the active organization and agent visible in every conversation.
  • Allow moving or copying selected memories between agents when needed.
  • Support per-agent permissions for repositories, SSH hosts, tools, and approval policies.

Example use cases

  • Organization A has separate agents for backend, frontend, infrastructure, and QA.
  • Organization B has a different set of agents with unrelated repositories and standards.
  • A personal workspace has experimental agents that do not pollute professional memory.
  • An infrastructure agent can know deployment procedures without exposing that context to unrelated projects.
  • A code-review agent can keep review preferences separate from implementation agents.

Security and UX safeguards

  • Memories should not cross organization boundaries unless the user explicitly moves or shares them.
  • Tool access should be scoped per organization and per agent.
  • The UI should clearly show which organization and agent are active.
  • Export, archive, and reset options should exist for individual agents.
  • Users should be able to inspect what memory or files belong to each agent.

Expected benefit

This would make Codex more scalable for long-term professional use. It would reduce context pollution, improve agent specialization, and make Codex safer and more predictable across multiple organizations, projects, and environments.

Suggested labels, if available: enhancement, agents, memory, skills, workspaces, organizations

Redaction check

This request uses generic organization and project examples only. It does not include real company names, private repository names, server names, credentials, internal paths, or client-specific information.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Support organization-scoped agents with isolated memory, skills, and project context