Separate configuration scope from access scope

Understand the approach

The word scope can describe several different things. Configuration scope answers where a server definition is stored and who may inherit it. OAuth scope describes permissions requested from an authorization server. Tool visibility describes which operations the client exposes. The user's task scope describes the work being delegated. Do not collapse these into a single permission decision: a project-shared server definition can exist while a teammate lacks service access, and a valid token can permit more than today's task authorizes.

Codex documents user configuration in ~/.codex/config.toml and project configuration in .codex/config.toml for trusted projects. That differs from the source guide's Claude local, project and user files and --scope syntax. A project entry is useful for reproducible non-secret connection details, but reviewing repository trust and managed requirements still matters. Sharing a URL is not sharing the right to retrieve all private content, and sharing an environment-variable name must not turn into committing its value.

For the lab, prepare a project-scoped description of the public Docs MCP without applying it. Then compare it with a fictional private ticket connector. Identify what can be checked into a repository, what stays with each user's credentials, and which operations should be exposed. Codex's enabled_tools and disabled_tools settings can narrow the presented set, with the deny list applied after the allow list. Those controls should match actual tool names; they do not replace the service's authorization or validate a tool's safety.

Generate the complete host-specific table, then in a chosen scratch configuration keep all three names in enabled_tools and put get_task in disabled_tools. After restarting the native client, inspect whether get_task is absent while list_tasks and read_task_snapshot remain. The standalone transcript still lists all three because it never reads Codex TOML. A hidden lookup also does not hide those records from read_task_snapshot. Project configuration, tool presentation and data authorization therefore have different tests. App/CLI/IDE on the same host share this connection; another machine cannot reuse the first machine’s executable path just by copying its file.

Practice and acceptance

What a server implements, what a host exposes and what a task authorizes remain different boundaries.

Try it step by step

1. Read the linked lab guide, inputs and expected outputs before running the exercise.
2. Create a four-column scratch table for configuration location, account authorization, tool exposure and delegated task; fill it for the Docs MCP.
3. Review the project's trust and existing configuration before proposing a project entry. Preserve unrelated servers and organization requirements.
4. For a fictional private service, list shareable non-secret details separately from user sign-in and credential handling.
5. Choose the smallest required operation set using the server's actual tool catalogue; do not invent allow-list names from a marketing description.
6. Ask Codex to explain the proposed configuration and its limits, then check that no claim of shared credentials or broader task authority has slipped into the plan.

A useful starting example

Illustration · adapt before use.

# Within the generated [mcp_servers.practice_tasks] table:
enabled_tools = ["list_tasks", "get_task", "read_task_snapshot"]
disabled_tools = ["get_task"]
# Deny applies after allow. This is a Codex-host setting, not a server ACL.

Check your result

• The proposed file path and format follow Codex rather than Claude conventions.
• Credentials are absent from the shared note and service permissions are treated separately.
• Any tool filter uses confirmed operation names and does not claim to enforce all service authorization.
• Local harness behavior and isolated native server discovery are distinguished from unrun app UI setup or model-selected tool calls.

Common mistakes

• Copying Claude's --scope project or .mcp.json into a Codex setup without checking the format.
• Assuming that adding a project connection grants every teammate the same data access.