Can the team use the new repository helper?
Environment & Tooling Management
Stop rebuilding your AI setup, one project at a time.
Bring tools, skills, instructions and configuration into one approved environment. Keep the right setup with the right project—not scattered across every client and computer.
See it in practice Explore capabilitiesReview a tool update
A new tool release asks for broader network access while the team keeps its approved revision.
ClaudeRepository helper
Project conversationThe current pinned helper works. The new release adds a network action.
The new release changes its permissions.
Tool update needs reviewScope review
- Active
- Approved pinned release
- Candidate
- Adds network access
- Next
- Bounded test and review
Test the candidate against the project fixture.
The test result and permission difference are ready for review. Everyone stays on the pinned revision until a reviewed release is activated.
Request rejected. No action was dispatched. A new request needs its own review.
Ready
WHY IT MATTERS
One workspace. Not one flat setup.
Skills, plugins, MCP servers, instructions and model settings become difficult to manage when each client and computer carries its own copy. A setup that worked yesterday can fail today because one tool changed, the wrong account was selected or a project loaded a different instruction revision.
DriftGate organizes that environment around approved profiles. Define the tools and configuration a project needs, bind the correct resources, release a reviewed revision and compare it with the state reported by each supported target. Keep legitimate project differences instead of forcing every workflow into one global configuration.
HOW IT WORKS
A reusable baseline. A project-specific environment.
A workspace supplies reusable defaults and mandatory rules. A project selects its repositories, tools, knowledge, resources and profile revision. A target binding connects that approved intent to a client account, enrolled device, container or other supported runtime context.
The representation can differ by target without changing its purpose. A hosted client and a local coding tool do not expose identical controls. Repository-owned instructions remain in the repository; DriftGate tracks the relevant identity, path and revision rather than making a competing editable copy.
Define
Select the project, reviewed tools and resource bindings.
Release
Pin an approved profile instead of silently activating every edit.
Apply
Change only managed settings on the intended target.
Verify
Compare approved intent with installed and observed state.
WHAT YOU CAN CONTROL
Environment & Tooling Management
T01Approved MCPs
Discover and assign reviewed MCP servers, tools and versions. A catalog entry is not blanket action permission.
See related workflowsT02Skills and plugins
Review, release, pin and update skills and client-specific plugins with provenance and compatibility.
See related workflowsT03Model management
Manage supported model preferences and observed settings without pooling subscriptions or provider quotas.
See related workflowsT04Environment sync
Apply approved profiles across enrolled contexts while preserving unmanaged settings and independent authorization.
See related workflowsT05Version control
Pin artifact and profile revisions. Activate upgrades or rollbacks deliberately, not on every source edit.
See related workflowsT06Infrastructure templates
Reuse reviewed runtime and deployment patterns with explicit prerequisites, ownership and approval.
See related workflowsT07Secrets and configuration
Distribute managed settings and opaque credential references, never raw secrets in portable profiles.
See related workflowsT08Drift detection
Compare expected, approved, installed, loaded and observed state. Explain differences and precise unknowns.
See related workflowsT09Tool sandboxing
Bound approved execution by qualified filesystem, network, credential, time and resource controls.
See related workflowsIN PRACTICE · EXAMPLE WORKFLOW
A working environment should travel. Credentials should not.
A developer joins a payments project while also working on a public marketing website. The projects need different tools, instructions, accounts and restrictions.
Resolve each project’s approved profile, repository-owned instruction revision and selected resource connections. Enroll the second client independently, apply only managed settings and compare reported state with the approved release.
See the workflowTHE INTENDED RESULT
The developer can do the project’s permitted work without copying a colleague’s sessions or inheriting another project’s access. Legitimate project differences stay intact.
THE OPERATIONAL RESULT
Keep a working setup. Understand every change.
Onboarding becomes a controlled setup journey rather than a folder of copied credentials. Debugging begins with the actual project and observed revision. Updates move through review and deliberate activation. A useful environment can be reused without making every project identical.
MORE WAYS TO USE IT
Find your next workflow.
SOFTWARE
Review the update before it changes your agents’ permissions.
A previously approved MCP or skill release adds a tool, broadens network access or changes its instructions.
MCP & tool governance
SOFTWARE
Read-only should be a permission. Not a request.
A coding assistant investigates a production problem but attempts a destructive database operation during diagnosis.
MCP & tool governance
SOFTWARE
Find the difference behind “it works on my other machine.”
One client succeeds at a project task while another has a stale skill, different endpoint or wrong resource-account selection.
MCP & tool governance
YOUR QUESTIONS
A little more detail.
Does every project get the same configuration?
No. Reuse approved workspace defaults while selecting the repositories, tools, instructions and resource connections appropriate to each project. Mandatory organizational restrictions still apply.
Does sync copy my login sessions?
No. A shared profile describes approved setup. Each client and resource connection retains its own authorization; portable configuration carries secret references, not raw credentials.
What is configuration drift?
It is a meaningful difference between approved intent and reported state: a stale skill, a wrong endpoint, an unexpected instruction revision or a different resource account. Intentional overrides remain distinguishable from problems.
BUILD WITH INTENTION