ChatGPT profile visibility: what workspace admins should decide
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
ChatGPT profile pages now show each member's message counts, Work and Codex token usage, activity streaks, top plugins and up to 12 Sites. OpenAI launched shareable profiles at DevDay on 29 September 2026. The shareable profiles help article says Business profiles are shared within the workspace by default, with an admin control under Workspace settings > Permissions & roles > Member profiles. In practice, the admin decides on day one whether every colleague can see how much everyone else uses ChatGPT and Codex.
This guide is for workspace admins and engineering leads. It covers what a profile exposes, when to change the default, and how to handle the shared skills that profiles help people discover.
What a ChatGPT profile exposes inside a workspace
A profile shows activity, not content. The help article lists chat message counts, Work and Codex token usage, activity streaks, top plugins, and up to 12 Sites the member chooses. Shared profiles do not show conversation titles or content. Viewers must be signed in, and links use the format chatgpt.com/u/username.
The defaults differ by account type:
| Account type | Default visibility | Who changes it |
|---|---|---|
| Personal | Private | The member |
| Business | Shared within the workspace | Admin, through Member profiles |
| Enterprise | Shareable profiles listed as coming soon | Not yet available, per the help article |
So the default is only a question for Business admins today. Enterprise admins have time to decide before the feature reaches them.
Should Business profiles stay visible by default?
Keep them visible if your culture already shares tool use openly and people use profiles to find each other's Sites and skills. Discovery is the stated purpose: Sites and plugins that others can find and reuse, and shared skills that teammates can discover.
Restrict them if usage numbers are likely to be read as a performance signal. A visible token count invites comparison. It rewards long sessions over short precise ones, and it can make people who work on hard problems with few prompts look idle. Once a manager screenshots a streak into a team channel, the number starts to steer behaviour.
There is also a middle path. Keep profiles visible but publish a short rule about what the numbers are for. That keeps the discovery benefit and names the misuse before it happens.
Usage numbers are adoption data, not performance data
Token usage and streaks show adoption: who is using the tools, and how often. They say nothing about whether the work met requirements, passed review, or needed rework. Use them to spot people who have not started, so you can offer help. Do not use them to rank people or teams.
If you want to know whether AI use improves delivery, measure the delivery. Our guide to measuring an AI workflow before scaling it sets out the measures we use: delivery time, review effort, rework, and accepted scope. Profile numbers can sit beside those as context. They should never replace them.
Shared skills need an owner and a review
Profiles make shared skills easier to find, and skill sharing is limited to the workspace. That is good for reuse and a new risk for quality. A skill is a reusable workflow made of instructions and resources. Once many people run it, a mistake in it repeats many times.
OpenAI's skill controls docs separate three paths with separate controls: ChatGPT workspace Skills, local filesystem skills used by Codex CLI and the desktop app, and plugins that bundle skills with connectors and MCP servers. Moving a skill between paths does not transfer ownership, sharing, role assignments, plugin installation state or connector authorization. Installing a plugin does not grant access to the connector or service it bundles.
For admins, that means one policy per path, not one policy for "skills". A practical rule: a workspace-shared skill needs a named owner, a short description of what it may and may not do, and a review before it is shared. Coding workflows can often live as a repository skill instead, where the normal code review applies.
Decision table for workspace admins
| Decision | Options | Our default |
|---|---|---|
| Member profile visibility on Business | Workspace-wide (default) or restricted | Keep visible, with a written rule on use of numbers |
| Use of token usage and streaks | Adoption signal, or performance input | Adoption signal only |
| Sites on profiles | Allowed for any Site, or workspace and private only | Check each Site's own audience before display |
| Workspace-shared skills | Anyone may share, or owner and review required | Named owner and review before sharing |
| Enterprise rollout | Decide now, or when the feature arrives | Decide now and record the reasons |
The defaults in the last column are ours, not OpenAI's. They follow the approach in our Delegate, Review, Own method: tools produce the work, people review it, and someone owns what gets shared.
What to watch in the first month
Look for three signals. Are profiles used to find Sites and skills, which you can check by asking the owners of shared ones whether new people reached out? Do usage numbers appear in team channels or reviews? And how many shared skills lack an owner? If numbers turn up in performance conversations, restrict visibility and repeat the rule.
Before you change anything, open your own profile, look at what colleagues can see, and write a one-sentence rule on what those numbers are for.