Allow Enabling/Disabling Default Codex Apps from CLI and Per-Client App Management

<img width="1139" height="655" alt="Image" src="https://github.com/user-attachments/assets/0d5484fa-c864-4e2d-ba5b-9d7efb598b0e" />

check

• codex_apps
• Auth: Bearer token
• Tools: adobe_photoshop.applyAdjustments, adobe_photoshop.applyEffects, adobe_photoshop.blurBackground, adobe_photoshop.getOptionsForAdjustments,
adobe_photoshop.instructEdit, adobe_photoshop.removeBackground, adobe_photoshop.selectSubject, adobe_photoshop.selectionByPrompt, adobe_photoshop.undoEdits,
adobe_photoshop.zeroCredits, gmail.apply_labels_to_emails, gmail.archive_emails, gmail.batch_modify_email, gmail.batch_read_email,
gmail.batch_read_email_threads, gmail.bulk_label_matching_emails, gmail.create_draft, gmail.create_label, gmail.delete_emails, gmail.forward_emails,
gmail.get_profile, gmail.list_drafts, gmail.list_labels, gmail.read_attachment, gmail.read_email, gmail.read_email_thread, gmail.search_email_ids,
gmail.search_emails, gmail.send_draft, gmail.send_email, gmail.update_draft

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #28443

Powered by Codex Action

Thanks for flagging #28443.

While there is some overlap in the underlying problem (unwanted apps/plugins being injected into the model context), I believe this request addresses a different and broader use case.

Issue #28443 is primarily a bug report stating that:

Per-plugin enabled = false settings are ignored for certain remote curated plugins.

The expected outcome of #28443 is that existing disable settings should work correctly.

This feature request goes beyond fixing that bug and proposes a more complete app-management architecture for Codex.

Key Differences

1. Explicit App Management

Instead of only fixing enabled=false, Codex should provide first-class commands for managing app visibility and availability:

codex apps list
codex apps enable <app>
codex apps disable <app>
codex apps remove <app>

This gives users direct control over which apps are exposed to a session.

2. Independent Configuration Per Client

Codex CLI and Codex Desktop/App currently appear to share app availability in ways that are not always desirable.

Many users want:

ChatGPT Web/Desktop
    ├── Gmail
    ├── Photoshop
    ├── Figma
    └── Other productivity apps

Codex CLI
    ├── GitHub
    └── Laravel Boost

without needing to globally disable apps everywhere.

A developer workflow and a ChatGPT workflow often have very different requirements.

3. Token and Context Optimization

Every unnecessary MCP server, app, skill, plugin, or tool definition contributes additional context that the model must process.

Providing a way to selectively load only required apps would:

• Reduce token consumption.
• Reduce prompt/context size.
• Reduce MCP initialization overhead.
• Improve session focus.
• Improve privacy through least-privilege access.

4. Session-Level Tool Selection

Example:

codex --apps github,laravel-boost

or

codex session --only github

Only the requested apps should be loaded into the session.

5. Per-Project Configuration with Global Override Support

In addition to global app settings, Codex should support project-level configuration files that can override the user's default tool/app configuration.

This would allow different projects to expose only the tools they actually require.

Example

Global configuration:

{
  "enabledApps": [
    "github",
    "gmail",
    "playwright",
    "figma",
    "laravel-boost"
  ]
}

Laravel project:

.codex/config.json

{
  "enabledApps": [
    "github",
    "laravel-boost"
  ]
}

Frontend project:

.codex/config.json

{
  "enabledApps": [
    "github",
    "figma",
    "playwright"
  ]
}

When entering a project directory, Codex would automatically apply the project configuration and override global defaults.

Configuration Priority

Project Configuration
        ↓
Workspace Configuration
        ↓
User Global Configuration
        ↓
System Defaults

CLI Examples

codex apps list

codex apps disable gmail --global

codex apps disable playwright --project

codex apps enable figma --project

codex apps reset --project

Benefits

• Different projects use different toolsets.
• Reduced context size and token consumption.
• Faster tool discovery and MCP initialization.
• Better security through least-privilege access.
• Reproducible team configurations stored in version control.
• Eliminates the need to manually toggle apps when switching projects.

Team Collaboration

.codex/
├── config.json
└── profiles/
    ├── frontend.json
    ├── backend.json
    └── security.json

This allows all team members and CI agents to use the same Codex environment without manual setup.

Real-World Example

A developer may have 20+ apps connected globally:

gmail
photoshop
figma
playwright
github
laravel-boost
...

But for a Laravel backend project, only:

github
laravel-boost

should be loaded.

The project configuration should automatically override global defaults, preventing unnecessary MCP tool definitions, skills, and app metadata from being injected into the model context.

Existing Related Functionality

Codex already supports configuration layering and profiles, which demonstrates that configuration precedence is a supported pattern. Extending that concept to app visibility and tool loading would fit naturally within the existing configuration model.

For these reasons, I believe this request is complementary to #28443 rather than a duplicate. A fix for #28443 would ensure disable flags work correctly, while this proposal introduces a broader mechanism for app lifecycle management, per-client separation, and project-aware tool loading.

Per-client app enablement needs to be recorded on the session, not only stored as config.

For each run, persist a tool/app manifest with app id, tool names, schema hash, source config, enabled/disabled reason, and surface/client. That gives users an audit trail for which schemas entered context and lets token regressions be traced to a specific app bundle.

---

_Generated with ax._