In June 2026, OpenAI turned on default plugin sharing for Codex inside ChatGPT Enterprise. A plugin one developer installs can now spread across a whole workspace without a separate approval step. For a busy development team that sounds convenient. For whoever owns security and compliance, it raises a sharper question: who approved that tool, and what can it see? Claude answers the same question differently through Skills, and the difference matters for any Australian team that has to show its working to a client or an auditor.
What Codex plugin sharing actually changes
Plugin sharing lets a tool installed by one engineer become available to the rest of the workspace automatically. The upside is speed. A useful integration reaches the whole team in minutes rather than being set up one machine at a time. The cost sits in visibility and control, and it lands on the people least likely to hear about a new tool early.
A shared plugin can read code, call external services, and act on data the moment it propagates, often before anyone has reviewed what it does.
Default-on sharing makes the safe choice, reviewing first, the one a team has to remember to make rather than the one the system enforces.
When a tool misbehaves, tracing which workspace member added it and when is slow if the audit trail is thin.
None of this makes Codex unusable. It means the governance work shifts onto your team, and you need a deliberate process to keep pace with a feature that is on by default.
How Claude Skills approach shared tooling
Claude Skills are reusable capabilities you define once and make available to a team, but the sharing model is built around explicit definition rather than silent propagation. A Skill is a named, version-controlled set of instructions and tools that a person chooses to publish. That small difference changes the governance posture in a way auditors notice.
A Skill is written down and reviewed as a unit, so what it does is legible before anyone runs it.
Publishing is a decision someone makes on the record, not a default that happens while attention is elsewhere.
Because Skills live in files you control, they fit normal code review, version history, and rollback.
The practical effect is that a Claude-based setup gives you a record of who added which capability and why. That is exactly what a client security review or an internal audit asks for, and it is hard to reconstruct after the fact if the tooling never captured it.
The governance questions that matter either way
Whichever tool a team picks, the same questions decide whether shared AI tooling is safe. Write the answers down before you scale usage, not after an incident forces the conversation.
Who can publish a shared tool, and who signs off before it reaches the whole team?
What data can each tool read, and does any of it fall under the Privacy Act?
How do you remove a tool quickly, and how do you know what it touched while it was live?
Where is the record a regulator, a client, or your own board could review later?
What this costs an Australian dev team
The expensive outcome is not the licence fee. It is a shared tool quietly reading source code or customer records that should have stayed inside a controlled boundary. A single data exposure handled badly can cost a small Sydney software firm well past $45,000 once incident response, client notification, and lost trust are counted. Against that, a short governance setup is cheap insurance.
A written tool-approval policy and a simple register of shared tools: roughly $8,000 to $15,000 to set up for a typical team.
A quarterly review of what is shared and what it can access: a few hours of work, not a project.
A named owner for AI tooling decisions, so approval is a clear responsibility rather than a gap nobody holds.
For most Australian teams the policy pays for itself the first time it stops the wrong tool from being shared with the wrong data. The cost of writing it down is small next to the cost of explaining to a client why a tool you never reviewed had access to their records.
A governance starter you can run this week
You do not need a heavy framework to get this right. A one-page standard covers most of the risk for either Codex or Claude, and it gives a new engineer a clear answer on day one.
List every shared AI tool, who owns it, and what it can access.
Require a named sign-off before any tool is shared across the workspace.
Default sensitive repositories and customer data to the most controlled option.
We help Australian development teams govern shared AI tooling with a Claude-first default, where every published Skill is reviewed, recorded, and reversible. If you want a tool-approval policy that holds up in a client security review, book a brainstorm.
