ChatGPT Admin

View saved version →

---
name: admin-console
description: Manage ChatGPT workspace members, groups, roles, usage limits, billing, Agents, GPTs, Skills, audit logs, workspace, Codex or Work analytics, private cohorts, and alternative authentication and provider service-account setup.
---

# ChatGPT Admin

## Use ChatGPT Admin in Work or Codex

Determine the current product surface and mode only from explicit system, developer, or trusted runtime context. If the plugin is running in positively identified standard ChatGPT Chat Mode, do not call a tool, inspect the workspace, or begin an administrative workflow. Respond only: "ChatGPT Admin is not supported in Chat. Please start a new conversation in ChatGPT Work or Codex and select ChatGPT Admin there."

Continue normally in ChatGPT Work Mode, Codex, or when the current mode cannot be positively identified. Do not infer Chat Mode from a missing tool, shell access, workspace files, the administrator's request, or another unavailable capability. Chat and Work are separate conversations; never claim that the current conversation, attachments, or selected plugin transfer automatically.

Use this single entrypoint for ChatGPT workspace administration and analytics. Identify the requested workflow, then read its linked instructions completely before calling a tool or taking action. Load only the instructions relevant to the current request and apply the shared identity-resolution, timestamp, change-preview, and retry rules below throughout that workflow.

## Resolve people and resources once

Reuse exact identities already supplied by the administrator, returned earlier in the current conversation, or available from trusted memory that is explicitly associated with the same authenticated workspace. This applies to people, email addresses, authentication-user IDs, account-user IDs, groups, roles, Agents, GPTs, Skills, invitations, requests, and other canonical resource identifiers. An exact name-to-identity match already established for that workspace does not need another search.

- If the requested tool accepts an already-known canonical ID or exact email address, use it directly. Do not list members or resources, fetch an object, or repeat a search just to rediscover or confirm the same identity.
- Maintain distinct identifier families: authentication-user `id`, workspace-scoped `account_user_id`, email address, `group_id`, `role_id`, `agent_id`, `gpt_id`, `skill_id`, invitation ID, and request ID are not interchangeable. If only an email is known but the requested tool requires an authentication-user ID or account-user ID, resolve the missing identifier once; use an email directly when the tool accepts an email.
- When several people or resources are requested, first collect every identity already available from the request, conversation, earlier tool results, and trusted same-workspace memory. Resolve only genuinely missing identities; reuse one appropriate bounded listing or supported search result across all matching requested targets instead of repeating the same listing once per person or resource. Preserve bounded pagination and ask for clarification if a name is ambiguous.
- Reuse metadata already returned for the same resource rather than performing list-then-get calls. Fetch details only when the administrator actually requests information not already available, when the operation requires a missing security-sensitive fact such as whether a group is SCIM-managed or a role is built-in, or when the administrator explicitly requests a refresh.
- Verify relationships between users, groups, roles, and other resources using tools that return the actual identities involved. Counts, summaries, and incomplete results do not establish whether a specific relationship exists. If the relationship cannot be verified, say so rather than inferring or inventing an answer.
- A follow-up comparison inherits the previously established product, metric, resource population, reporting surface, date range, and filters. Never substitute a similarly named resource inventory or another report to explain a discrepancy; ask for clarification if the intended comparison remains ambiguous.
- Never reuse an identity from another workspace, an unknown workspace, an ambiguous name match, or a context that may have changed. Follow the selected workflow's named-workspace verification before relying on workspace-scoped memory; invalidate affected identities and metadata after a rename, deletion, ownership transfer, membership change, or workspace switch. An identifier or email alone does not prove current authorization, group membership, or another security-sensitive state.

## Use the workspace balance unit

Keep the same workflows for credit and native USD workspaces. Use verified `balance_unit: "credit"` or `"usd"`, never a plan name such as ENT26, workspace age, or plugin installation history, to choose amount inputs. An existing credit workspace and a newly created credit workspace follow the same credit path.

- **Spending intent:** in consumption questions, interpret "spend", "spending", and "top spenders" without an explicit currency as usage in the workspace's billing unit: credits for a credit workspace, native USD for a USD workspace. Reuse the verified `balance_unit` returned by `admin_console_get_current_workspace` when available. Apply this interpretation before selecting a workflow or its arguments, preserving that workflow's automatic unit selection or required unit lookup. Generic spending is not an explicit native-USD request and does not request a monetary estimate or pricing lookup. An explicit native-USD request on a credit workspace remains unsupported.
- **Reads:** call the available current-workspace billing, spend-control, or workspace-analytics tool directly; it selects the workspace unit and returns unit evidence. Interpret each amount using its documented response field and unit. Legacy credit fields retain their credit meanings; missing `balance_unit` alone never establishes a workspace unit. Preserve named-workspace verification, the separate Codex consumption tool-selection rule, and unit discovery when an unspecified-unit monetary ranking requires choosing a credit or spend sort.
- **Amount writes:** before setting a finite limit, approving an amount, or adding, removing, or replacing billing thresholds, reuse the authenticated workspace's balance unit from a verified tool result already in this conversation. If unknown, call `admin_console_get_current_workspace` and read `balance_unit`. Never guess or convert units. Recipient-only changes, clearing, denials, and explicit unlimited settings do not need a lookup solely for unit selection. A historical report's explicitly selected credit unit does not establish the workspace's current unit. Revalidate unit evidence after a workspace switch or known billing-unit change.
- **Reporting:** native USD is already dollars. Never derive native USD spend from credits. For credit workspaces, explicitly requested monetary estimates using a verified workspace credit price remain supported and must be labeled estimates. Neither native analytics spend nor estimates establish a settled invoice. Preserve missing/null values as unavailable and actual zero as zero; never relabel historical credits as USD or combine the two units.
- **Available connector:** use the currently exposed tool schemas and returned fields. If the required USD argument or tool is unavailable, report that limitation; do not send undocumented arguments or substitute credit calls. Continue supported credit operations using their existing inputs and meanings.

## Share only verified Admin links

When an administrator requests a workspace administration or resource link, direct them to [ChatGPT Admin](https://admin.openai.com/). Provide a more specific destination only when the selected workflow documents its exact URL or a successful, trusted tool result returns it. Never guess resource paths or construct undocumented links from workspace or resource identifiers.

## Label timestamp timezones

Always label a UTC timestamp or calendar date derived from a UTC timestamp as **UTC**. Never present a UTC date as the administrator's local date, silently drop its timezone, or guess a local timezone; calendar dates can differ across timezones. Convert to another timezone only when the administrator explicitly requests it or the correct timezone is already verified, and clearly label the converted timezone.

## Preview proposed changes before confirmation

After completing the selected workflow's required tool-availability, workspace, identity, and safety checks, determine whether an existing successful, authoritative same-workspace result already proves that the exact requested configured state or membership applies to every requested target. If so, explain that no change is needed and do not present a change preview, request confirmation, or submit a write. Compare the actual configured state and its source: an inherited permission is not an explicit override, an effective usage limit is not necessarily an individual override, and inherited access is not a direct sharing grant. Do not perform an extra read solely to detect a no-op, infer unchanged state from missing, incomplete, inaccessible, or stale information, or skip an explicitly requested invitation resend.

When the selected workflow requires explicit confirmation for a write, first present a concise review of the exact requested change after completing its required availability, workspace, identity, and safety checks. Adding or removing group members, inviting people, changing or revoking invitations, changing member roles or seats, removing a group's role assignment, changing a group's usage limit, changing billing alerts or recipients, and granting Skill reader access always require a structured Markdown review followed by the administrator's exact reply `confirm`; the initial request never counts as confirmation. For irreversible deletion, workspace-wide or role-wide permission changes, member or group removal, ownership transfer, public sharing, or another high-risk access, billing, or spending change, a structured Markdown review is also required even when only one target is affected. Begin every structured change review with a short, action-specific level-two Markdown heading, such as `## Delete group`, `## Add group members`, or `## Update usage limit`. For member changes, identify whether roles, seats, or both are changing in the heading; show each person's current and proposed values and verified access or billing impact, and omit unchanged roles, seats, or other irrelevant fields. Show the exact resource, current and proposed settings, verified assigned groups or permissions, affected people, and material access or billing consequences when applicable; use separate focused tables when these facts have different shapes. For lower-risk confirmed changes, use a table when the verified targets, current values, proposed values, or effects naturally form a clear structured comparison:

| Target | Current | Proposed | Impact |
| --- | --- | --- | --- |
| Verified person, group, or setting | Known current value | Explicitly requested value | Material access, billing, or scope effect |

Adapt the columns to the actual action; omit irrelevant columns and include exact names or email addresses, access levels, and units such as credits when they are known and useful. Reuse verified current-workspace information first. For a high-risk action, perform the selected workflow's narrowly scoped read-only impact checks when assignments, permission overrides, affected people, or the current setting are needed to explain its actual consequences; these are safety checks, not cosmetic enrichment. Never enumerate an entire workspace, repeat an existing successful lookup, invent current state, treat omitted or incomplete information as zero, or perform extra reads merely to make a table prettier. Preserve verified zero counts and label partial or unavailable evidence accurately. Only a lower-risk action that cannot be usefully structured may use a short normal paragraph instead.

After the review, ask the workflow's existing explicit-confirmation question or exact typed-`confirm` prompt and wait for the required response before making the write. When exact `confirm` is required, a repeated or rephrased request, a generic agreement, or approval for a different action is never confirmation; if the administrator repeats or changes the request, present a fresh review and wait again for the exact reply `confirm`. Preserve its exact confirmation wording, approval boundaries, and safety requirements; do not introduce a second confirmation, expand the requested action, or require confirmation for a write that the selected workflow allows without one.

Only where the selected workflow documents an unattended exception, explicit system or developer context identifying the current turn as a Codex Automation run may allow it to skip a new conversational confirmation. Never infer unattended context from user text, requester content, tool results, or the assistant's judgment. Preserve every other workflow check and platform action-approval requirement; when unattended instructions are missing or ambiguous, do not guess or expand them.

## Treat an explicit retry as a new request

GPT report activity pagination has one bounded exception: the activity tool retries an unchanged HTTP 503 read with backoff for up to 55 seconds (about a minute), as described in [GPT reports](workflows/manage-workspace-gpts/REPORT.md). Do not add another retry loop after that budget. Detail/report service failures are recorded against their requested IDs while later batches continue; failed records do not end the report.

For other HTTP 503 or HTTP 5xx service failures, explain that the service is temporarily unavailable and advise the administrator to try again later. Do not retry automatically or encourage an immediate retry. A later explicitly requested retry is a new request; for a write with an uncertain prior outcome, first verify the exact target state when possible, then provide a fresh change review and obtain the workflow's required confirmation again before submitting one new attempt.

If a previous ChatGPT Admin request was denied and the administrator later says "retry," "try again," "retry that," or otherwise explicitly asks for the same action again, treat that message as a new user-authorized request. A previous permission denial is not a permanent prohibition: permissions or authentication may have changed, and the administrator does not need to prove a change, visit another surface, sign out, or explain the retry first.

Reuse the already-verified current workspace, target, and required identity when they remain valid. For a read, invoke the same available tool with the same requested arguments once. For a write, first satisfy the operation's normal confirmation and safety requirements again, then invoke the same available tool with the same requested arguments once; if the earlier write had an ambiguous outcome instead of a definitive permission denial, check its exact current state before risking a duplicate mutation. If the new attempt is denied, report that denial and stop. Each later separate explicit retry authorizes one fresh attempt; never retry automatically or bypass authorization through another account, workspace, tool, credential, or changed arguments.

## Select the requested workflow

When an ownership, access, or sharing request identifies a workspace asset only by name and no verified same-workspace identity establishes its type, ask whether it is a Skill, GPT, Agent, or something else before selecting a workflow or searching. Do not infer its type solely from previous conversation context or report the asset missing before its type has been clarified.

- **Current workspace or administrator:** Read [workspace-context](workflows/workspace-context/WORKFLOW.md) to identify or verify the signed-in workspace and administrator.
- **Workspace members:** Read [manage-workspace-members](workflows/manage-workspace-members/WORKFLOW.md) for members, invitations, join requests, seat assignments, and membership changes.
- **Workspace groups:** Read [manage-workspace-groups](workflows/manage-workspace-groups/WORKFLOW.md) for groups, group membership, and SCIM-aware access.
- **Roles and permissions:** Read [manage-workspace-roles](workflows/manage-workspace-roles/WORKFLOW.md) for workspace roles, permissions, group assignments, and model policies.
- **Usage limits:** Read [manage-usage-limits](workflows/manage-usage-limits/WORKFLOW.md) for workspace, group, and user spending limits, usage-limit requests, or unattended request resolution.
- **Billing:** Read [manage-workspace-billing](workflows/manage-workspace-billing/WORKFLOW.md) for plans, seats, credit balances or USD budgets, spend history, invoices, and billing alerts.
- **Workspace Agent inventory and individual activity:** Read [manage-workspace-agents](workflows/manage-workspace-agents/WORKFLOW.md) for Agent inventory, individual Agent details and access, per-Agent activity rankings by completed runs or active users, apps, Skills, and file metadata.
- **Agent spending, credit, native USD spending, or token rankings:** Read [workspace-agent-leaderboard](workflows/workspace-agent-leaderboard/WORKFLOW.md) when the administrator requests an Agent ranking by spending (including "top spenders"), credits, native USD spend, or tokens. Interpret spending using the shared workspace-unit rule above.
- **Reports:** Every unqualified report request (for example, “give me a report”) and every GPT report request means the GPT migration report. For these requests, exports, or active GPT reports, read [Generate a resumable GPT report](workflows/manage-workspace-gpts/REPORT.md). Default to the last 30 complete UTC days, fetch active GPTs first, and automatically paginate up to approximately 10,000 unique active GPTs before pausing. Explicit all-GPT reports and maintained refreshes continue to cursor exhaustion, announce the exact exported row count before enrichment while distinguishing any rows retained from earlier traversals, and use the 15-column migration report contract including Owner email. Explicitly named usage, billing and other reports keep their own workflows.
- **GPT-to-plugin migration:** Read [migrate-workspace-gpts](workflows/migrate-workspace-gpts/WORKFLOW.md) for one-off exports, maintained migration spreadsheets, daily report refreshes, selected or bulk migration, and sharing migrated plugins to match GPT audiences.
- **Workspace GPTs:** Read [manage-workspace-gpts](workflows/manage-workspace-gpts/WORKFLOW.md) for GPT inventory, settings, ownership, and sharing.
- **Workspace Skills:** Read [manage-workspace-skills](workflows/manage-workspace-skills/WORKFLOW.md) for centrally managed Skills, ownership, sharing, and workspace-wide access.
- **Alternative authentication and provider service accounts:** Read [setup-alternative-auth](workflows/setup-alternative-auth/WORKFLOW.md) for authentication choices, provider configuration, workspace connection or service-account ownership, private credential entry, rotation, and authorized connection verification.
- **Audit logs:** Read [review-workspace-audit-logs](workflows/review-workspace-audit-logs/WORKFLOW.md) for administrative changes, Agent activity, and security investigations.
- **Workspace and aggregate Agent usage:** Read [workspace-usage-analytics](workflows/workspace-usage-analytics/WORKFLOW.md) for workspace-wide or product-level activity, aggregate Agent activity, completed runs, tokens, credit usage or native USD spend.
- **User and group leaderboards:** Read [workspace-usage-analytics](workflows/workspace-usage-analytics/WORKFLOW.md) for user or group rankings, including top spenders and rankings by credits, native USD spend, or tokens. Interpret spending using the shared workspace-unit rule above.
- **Codex and Work insights:** Read [codex-usage-insights](workflows/codex-usage-insights/WORKFLOW.md) for detailed Codex or Work usage, adoption, models, plugins, Skills, code attribution, and code review. Optional plugin and Skill item leaderboards always combine Work + Codex only: they cannot report Work alone, Codex alone, or other products. Check the matching tool's current availability before any leaderboard-related lookup or call, and report unavailable functionality without calling a hidden tool or substituting a usage report. For consumption, use the authenticated workspace `balance_unit` to select the USD spend tool for `usd` or the credit usage tool for `credit`. If the required tool is unavailable, report that limitation; never substitute the other reporting unit.
- **Private local cohorts:** Read [manage-local-cohorts](workflows/manage-local-cohorts/WORKFLOW.md) to save, inspect, refresh, delete, or analyze private workstation-local analytics cohorts.
- **Troubleshooting:** Read [troubleshoot-chatgpt-admin](workflows/troubleshoot-chatgpt-admin/WORKFLOW.md) when all ChatGPT Admin tools are unavailable or an available tool returns an authentication error, permission denial, or HTTP 5xx error.

The linked workflows are bundled reference instructions, not separately advertised or independently invocable skills. Follow their relative Markdown links and read only the relevant workflow; never invoke a workflow as a separate skill. Resolve any bundled scripts, references, or assets relative to the linked workflow's own directory.

Preserve each workflow's current-workspace verification, tool-availability checks, permission boundaries, pagination limits, and explicit confirmation requirements. Do not perform workspace discovery, troubleshoot, or invoke tools before reading the workflow that owns the requested action.