Claude Code Governance

Govern Claude Code Before It Acts

Control commands, file changes, repository actions and tool calls with organizational policy before Claude Code executes them — in the IDE where your developers already work.

Allow. Warn. Require approval. Block.

No sales call required. Works with Claude Code in VS Code.

  1. Claude Code action
  2. Oconee Runtime
  3. Policy + context
  4. Allow / Warn / Approval required / Block

Runtime enforcement

Every governed action takes the same path.

Claude Code proposes an action. Oconee evaluates it against your policy and the context it targets. A decision comes back before anything executes.

Shell command

A destructive command against infrastructure the agent was not asked to touch.

Command intent is classified, then matched against organizational policy.

Block

File change

Edits to application code in a workspace your organization has classified as development.

The workspace classification and the change itself both resolve as low risk.

Allow

Repository action

A push or branch change affecting a protected branch.

Repository context raises the action above what policy clears automatically.

Approval required

Where this fits

Native permissions are the floor, not the governance layer.

Claude Code ships real permission controls and you should use them. What they are not designed to be is your organization's policy system.

Consistent across engineers

Local settings are per-developer and drift. Organizational policy is defined once and applies to everyone who connects.

Aware of your context

Whether an action is acceptable often depends on which repository or workspace it targets — context your organization defines, not the tool.

Evidence you can produce

Governance you cannot evidence is difficult to assert. Decisions are recorded as they are made.

Use both, deliberately. Our own guidance is to pair centralized policy with Claude Code's managed deny rules. Rules Claude enforces itself hold regardless of whether any extension is running, which makes them the right place for the handful of things that must never happen. Oconee is the layer above that: the organizational policy, the context and the record.

Coverage

What your organization can control.

Enforcement sits on Claude Code's prompt and tool-use path, so coverage follows the actions an agent actually takes.

Command execution

Shell commands Claude Code proposes are classified by intent before they run, so a destructive command is treated differently from listing a directory.

File operations

Writes and edits are evaluated against the change itself and the sensitivity of the workspace it targets.

Repository and Git activity

Git commands, commits, branch and remote changes, pushes and merge intent are all governed as actions rather than inferred after the fact.

Tool invocation, including MCP

Enforcement sits on Claude Code's tool-use path, so it evaluates the tool being called and its arguments — not a fixed list of names. MCP tool calls are governed as invocations; Oconee does not sit in front of an MCP server.

Prompt submission

A prompt can be evaluated before it is sent, which is where sensitive content is caught earliest.

Secrets in tool arguments

Where a secret appears in the arguments of an otherwise reasonable call, the arguments can be rewritten to remove it instead of failing the whole action.

Workspace and repository context

The same action can resolve differently depending on which repository or workspace it targets, using classifications your administrators set centrally.

Agent autonomy

Oconee records whether a human was approving each tool call, so unattended agent activity is visible as such.

Decisions

Four outcomes, and the difference matters.

Most governance stories are told as a binary. Velocity comes from the two decisions in the middle.

Allow

The action clears policy and proceeds. Developers notice nothing, which is the point.

Warn

The action proceeds with policy guidance surfaced to the developer, for the cases where a nudge is enough.

Approval required

The runtime holds the action for human authorization, and the request is recorded for an authorized reviewer to approve or deny.

Block

The action is denied before it executes, and the decision is written to the audit trail.

Developer workflow

Govern Claude Code Where Developers Already Work

Adoption is an extension install, not a platform migration. Nobody changes how they work.

01

Install the extension

The Oconee Runtime extension installs from the Visual Studio Marketplace like any other.

02

Connect your organization

Sign in once. The extension picks up the organization you belong to.

03

Policies arrive

Your organization's policies apply without each developer configuring anything.

04

Keep using Claude Code

No change to how anyone works. Oconee evaluates governed actions as Claude Code proposes them.

For engineering leadership

Let teams use AI agents without giving every agent unlimited authority.

The question a CTO is actually asked is not whether engineers may use AI. It is what the AI is permitted to do, and how that is evidenced.

One set of controls, every engineer

Policy lives with the organization, not in each developer's local settings, so the controls are the same across the team.

Different rules for different repositories

Classify workspaces and repositories centrally. That classification reaches the Claude Code integration and changes how actions there are judged.

Evidence, not anecdotes

Governed actions and their decisions are recorded, so what agents did and what was stopped is answerable after the fact.

Guardrails instead of bans

Let engineering teams use AI agents without giving every agent unlimited authority.

Not a single-tool plugin

Start with Claude Code. Extend the same governance model.

Claude Code is the clearest use case today, and it is not the boundary of the product. The same policy engine and the same four decisions govern AI activity in the editor and in the browser, so the model you adopt here is the one you keep.

Coding agents

Claude Code activity governed on the prompt and tool-use path, in the IDE.

The editor itself

AI activity inside VS Code is governed by the same extension and the same policies.

The browser

AI tools used in the browser are covered by the published browser extensions, reporting into the same policy and evidence layer.

Start governing Claude Code today.

Create an account, complete the onboarding wizard, install the extension, and begin governing agent activity. No demo to sit through and no procurement call to book first.

See pricing

No sales call required.

Questions

Claude Code governance, answered.

What is Claude Code governance?
Claude Code governance means applying your organization's policy to what a coding agent does — the commands it runs, the files it changes, the repository actions it takes and the tools it calls — rather than only to what it is allowed to read. Oconee Runtime evaluates those proposed actions before they execute.
How does Oconee Runtime work with Claude Code?
Oconee installs as a VS Code extension and registers with Claude Code's hook interface. When Claude Code is about to submit a prompt or use a tool, Oconee evaluates the action against your organization's policy and the context it targets, then returns a decision: allow, warn, require approval, or block.
Does Oconee replace Claude Code's own permissions?
No. Oconee is an additional organizational layer, not a replacement. Claude Code's native permission settings still apply, and Oconee's own documentation recommends pairing centralized policy with Claude Code's managed deny rules, because rules Claude enforces itself cannot be affected by a failure in any extension.
Can Oconee block Claude Code actions?
Yes. A blocked action is denied before it executes and the decision is recorded. Oconee can also rewrite a tool call's arguments — for example to remove a secret — so that a reasonable action can proceed without the sensitive value.
Does Oconee work in VS Code?
Yes. VS Code is the primary adoption path. The Oconee Runtime extension is published on the Visual Studio Marketplace, and it governs both Claude Code activity and AI activity in the editor itself.
Can policies be managed centrally?
Yes. Policies are defined for the organization and apply to developers without per-machine configuration. Administrators can also classify workspaces and repositories centrally, and that classification changes how actions targeting them are evaluated.
Does Oconee support coding agents other than Claude Code?
Claude Code is the most direct integration, but Oconee is not Claude-specific. The same policy engine and decision model govern AI activity in the editor and in the browser, which is why starting with Claude Code does not mean adopting a single-tool product.
Do I need to schedule a demo?
No. Onboarding is self-service: create an account, complete the onboarding wizard, install the extension and begin governing activity. No sales call is required.