Claude Code for Teams - Tygart Media

Tygart Media

Category: Claude Code for Teams

  • Claude Code Server-Managed Settings: The Admin Console Push That Replaces Your MDM Pipeline

    Claude Code Server-Managed Settings: The Admin Console Push That Replaces Your MDM Pipeline

    Last week I argued that if you have more than a handful of engineers on Claude Code, repo-level .claude/settings.json is not enough — you need managed-settings.json deployed through MDM. That is still true. What changed in 2026 is that you no longer need an MDM team to roll it out.

    Claude Code now supports server-managed settings: a remote configuration tier pushed from the Claude.ai admin console, with no file on disk and no MDM involvement. If you are on the Team plan running Claude Code 2.1.38+ or the Enterprise plan running 2.1.30+, this is available to you today, and most platform teams I talk to are still treating MDM-deployed managed-settings.json as the only option.

    It is not. And the precedence rules matter.

    The New Top of the Settings Hierarchy

    Claude Code’s settings stack already had a clear order — repo > user > project > local — with managed settings sitting on top of all of them as the unoverridable tier. Server-managed settings now sit at the same top tier alongside MDM and the on-disk managed-settings.json file. Within that managed tier, the documented precedence is:

    1. Server-managed settings (admin console push)
    2. MDM / OS-level policies (Jamf, Kandji, Group Policy, Intune)
    3. managed-settings.json on disk (the file we deployed last week)
    4. HKCU registry (Windows)

    Server-managed wins. If you push a policy from the admin console that conflicts with a fleet managed-settings.json deployed by MDM, the server policy applies. That is the entire point.

    What This Actually Replaces

    For organizations without a mature endpoint management pipeline — which is most companies smaller than a couple hundred engineers — the old path looked like this: get IT to package a JSON file, push it through Jamf or Group Policy, verify on a pilot machine, then deploy fleet-wide. Two-week ticket minimum.

    Server-managed settings collapse that to: log into the admin console, write the policy in the UI, save. Claude Code clients fetch the new policy at startup and re-poll hourly during active sessions. No reboot. No reinstall. No ticket.

    This is a real change in posture. The friction that kept smaller teams from deploying any managed policy at all just dropped to near zero.

    The Approval Gate Most Teams Will Hit

    Server-managed settings have one behavior MDM-deployed settings do not: certain categories require explicit user approval before they apply on a given machine. The current list per the docs:

    • Shell command settings (custom commands surfaced to the model)
    • Custom environment variables (anything injected into the model’s process env)
    • Hook configurations (pre/post-tool-use hooks)

    These three need the user to click through an approval prompt the first time the new policy hits their client. Deny rules in permissions.deny, the audit log path, telemetry settings, default model — those apply silently.

    The reasoning here is sound: a malicious admin (or a compromised admin account) could otherwise inject a hook that exfiltrates every prompt or a shell command that pipes diffs to an external endpoint. Approval gating those three categories means a developer at least sees the change before it takes effect. It also means your “push the new hook policy fleet-wide” plan has a manual confirmation step you cannot skip.

    If you need silent enforcement of hooks or shell commands, MDM-deployed managed-settings.json still does that without the prompt. Use the right tool for the right setting.

    What Belongs on the Server, What Belongs in MDM

    After running both for two weeks across a small fleet, the split that has held up:

    Push from the admin console:

    • permissions.deny rules that should be hot-updatable when a new exfil vector is discovered
    • Default model pinning (when you want to change it without re-deploying)
    • Telemetry and audit log endpoints
    • Anything you want to A/B across user groups (more on this in a second)

    Keep in MDM managed-settings.json:

    • Hook configurations you need to enforce silently
    • Shell command allowlists that must apply before first launch
    • Anything that needs to survive the user being signed out of their org account

    The reason for the second list is that server-managed settings only apply once the user authenticates with org credentials. A fresh laptop with a developer running claude before signing in gets no server policy. MDM-deployed settings apply from the first invocation.

    Group-Targeted Policies Are the Sleeper Feature

    Anthropic added user groups to the admin console earlier in 2026. Groups can be created manually or synced from an IdP via SCIM, and each group can be assigned a custom role plus its own spend limit. The piece most teams have not connected yet: server-managed settings respect group membership.

    This means you can push one permissions.deny policy to the “Security” group and a different one to the “Platform” group without writing two separate managed-settings.json files and pushing them through MDM with different scoping. Write two policies in the console, assign to groups, done. Group membership changes via SCIM propagate within the hour-long polling window.

    For a 200-engineer org that previously needed Jamf smart groups + MDM JSON variants to do the same thing, this is significant.

    Verification Workflow

    The same verification workflow from the MDM-deployed setup still applies, with one addition:

    1. Push the policy in the admin console
    2. On a test machine, run claude config list — server-managed settings should appear flagged as such
    3. Attempt a denied action, confirm immediate block
    4. If hooks or shell commands are in the policy, walk through the approval prompt
    5. Sign the test user out, sign back in, confirm policy reapplies

    The sign-out test matters because that is where server-managed differs most from on-disk managed settings — the policy is bound to the org-authenticated session, not the machine.

    Model Versions for Org-Wide Pinning

    If you pin a default model via server-managed settings, the current strings are: claude-opus-4-7 (flagship), claude-sonnet-4-6 (workhorse), and claude-haiku-4-5-20251001 (fast). Verify against the live model list at docs.anthropic.com/en/docs/about-claude/models before deploying — model strings change frequently and pinning to a deprecated one will silently break agent runs.

    Where Server-Managed Settings Lose

    Three real limitations:

    1. No silent hook/shell-command enforcement. User approval is mandatory for those three categories.
    2. No effect before org auth. Pre-auth sessions ignore server policy entirely.
    3. No fine-grained rollback. Console changes apply globally within the hour. There is no canary group, no staged rollout percentage, no “apply to 10% of fleet for 24 hours” toggle. If you push a bad deny rule, every active session picks it up at next poll.

    Mitigate the third one by maintaining a single non-production test group that you deploy to first, wait 90 minutes, then promote the policy to broader groups. It is a manual canary, but it is the canary you have.

    The 20-Minute Rollout for a Team Already on Team Plan v2.1.38+

    1. Open the admin console at claude.ai → Settings → Claude Code policies
    2. Write a minimum-viable policy: deny curl, wget, rm -rf /, .env reads, credential files
    3. Assign to a single test group (one user)
    4. On that user’s machine, run claude config list — confirm the server policy appears
    5. Try three denied actions, confirm all blocked
    6. Expand assignment to one team
    7. Wait 24 hours, watch for tickets
    8. Roll org-wide

    The whole sequence takes longer than it runs because of the wait windows, not because of the work. The actual work is twenty minutes.

    Why This Article Exists

    The MDM-deployed managed-settings.json approach from last week is still the right answer for orgs that need silent, pre-auth policy enforcement. For everyone else — which is most teams adopting Claude Code in 2026 — server-managed settings are the easier path and most platform teams I talk to do not know they exist yet. Admin console push, no on-disk file, no MDM dependency, group-scoped via SCIM. If you are on a recent Team or Enterprise plan, this is the deployment posture you actually want.

    Sources

    • docs.anthropic.com/en/docs/about-claude/models (model version strings)
    • code.claude.com/docs/en/server-managed-settings (server-managed settings docs)
    • code.claude.com/docs/en/admin-setup (admin setup reference)
    • support.claude.com/en/articles/11845131-use-claude-code-with-your-team-or-enterprise-plan (Team/Enterprise Claude Code usage)
    • support.claude.com/en/articles/13799932-manage-groups-and-group-spend-limits-on-enterprise-plans (group management + spend limits)
    • support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning (SCIM provisioning)
    • claude.com/product/claude-code/enterprise (Enterprise plan overview)
    • anthropic.com/news/claude-code-on-team-and-enterprise (admin controls launch)

    📖 Recommended Reading in Claude Code Insider

  • Claude Code managed-settings.json: The Org-Wide Policy File Most Teams Skip

    Claude Code managed-settings.json: The Org-Wide Policy File Most Teams Skip

    Last week I wrote about the three-file split every team should set up in their repo: CLAUDE.md, .claude/settings.json, and .claude/settings.local.json. That gets a team to a sane shared baseline. It does not stop a single engineer with admin rights on their laptop from disabling every guardrail you wrote.

    If you are deploying Claude Code to more than a handful of engineers — anyone past Series B, anyone regulated, anyone whose CISO has asked a single pointed question about AI tooling — repo-level settings are insufficient. The control you want is managed-settings.json, and most teams I talk to either do not know it exists or have not deployed it.

    Where managed-settings.json Actually Lives

    Claude Code reads settings in a strict precedence order. Managed settings sit at the top and cannot be overridden by anything a user does in their repo, their home directory, or their environment. The file location depends on the OS:

    • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
    • Linux / WSL: /etc/claude-code/managed-settings.json
    • Windows: C:\Program Files\ClaudeCode\managed-settings.json

    You push the file via whatever you already use to manage developer machines. On macOS that is MDM — Jamf, Kandji, Mosyle. On Windows it is Group Policy Preferences. On Linux fleets, your config management tool of choice — Ansible, Chef, whatever survived your last platform team rewrite. The file does not need to be created by Claude Code itself. It just needs to be present at the path above, owned and writable only by an admin account, and readable by the user running claude.

    The One Rule That Earns Its Keep: permissions.deny

    Of every field in managed-settings.json, the one that pays for the entire deployment effort is permissions.deny. Deny rules at the managed-settings tier take effect regardless of any allow or ask rules at lower scopes. A user cannot grant themselves permission to do something an admin has denied — not in their project settings, not in their personal settings, not via a one-time CLI flag.

    Concretely, here is a minimum-viable managed file for a team that wants to stop the obvious foot-guns:

    {
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(rm -rf /*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./**/credentials*)",
      "Read(./**/*secret*)"
    ]
  }
}

    That blocks Claude from curl-ing arbitrary URLs (the most common vector for accidental data exfiltration in agentic loops), reading anything in an .env file, and deleting filesystem roots in a Bash one-liner gone wrong. It does not stop legitimate work. It stops the long tail of “I didn’t realize it would do that.”

    The Drop-In Directory Is the Underrated Piece

    The single-file model breaks the moment you have more than one team contributing policy. Security wants curl blocked, platform wants kubectl delete blocked, the data team wants reads against the /data/prod/ mount blocked. Funneling all three through a single admin-owned file becomes a coordination tax.

    Claude Code supports a drop-in directory at managed-settings.d/ in the same parent directory as managed-settings.json. Files in that directory are merged alphabetically — same convention as systemd and sudoers.d. Layout looks like this:

    /Library/Application Support/ClaudeCode/
├── managed-settings.json          # base policy
└── managed-settings.d/
    ├── 10-security.json           # security team owns
    ├── 20-platform.json           # platform team owns
    └── 30-data.json               # data team owns

    Each team owns one file. They push their fragment through their own MDM channel without touching the others. Merge order is alphabetical, so the number prefix matters — later files override earlier ones for any overlapping keys, but permissions.deny rules always accumulate. Nothing a later file does can unblock something an earlier file denied.

    What Belongs in Managed Settings — and What Does Not

    Managed settings is a heavy hammer. Use it for things that must not be overridable. Everything else belongs in the repo’s .claude/settings.json, where engineers can iterate without filing a ticket.

    Belongs in managed:

    • Deny rules for credentials, network egress, destructive shell operations
    • Telemetry / opt-out flags if your contract with Anthropic requires training data opt-out
    • Default model if you have a real reason to pin — most teams should let repos choose
    • Audit log paths if you are forwarding to a SIEM

    Does not belong in managed:

    • Project-specific subagents or hooks (these live in the repo)
    • CLAUDE.md content (repo)
    • Allow rules — these are better as defaults at the repo scope, where engineers can adjust per-task

    Verifying the Policy Is Actually Active

    Pushing a config file is not the same as enforcing one. After deployment, run claude config list on a test machine and confirm the managed entries show up. Then attempt something the deny rule blocks — try a curl command, ask Claude to read an .env. The denial should be immediate and unambiguous, not a quiet skip. If a user can override it from their repo settings, the file is not at the right path or not readable by the user account running claude.

    Model Selection at the Org Level

    If you do pin a default model in managed settings — and I would argue most teams should not — read the model docs at docs.anthropic.com/en/docs/about-claude/models before writing the version string. Model identifiers change. As of this writing the workhorse is claude-sonnet-4-6, the flagship is claude-opus-4-7, and the fast option is claude-haiku-4-5-20251001. Hardcoding a model string in a managed file that nobody touches for six months is how you end up running last year’s model in production.

    Where This Approach Loses

    Managed settings cover the local Claude Code process. They do not cover the Anthropic Console, the Claude web app, or any MCP server an engineer connects to manually. If your threat model includes data leaving via the web app, managed settings on developer laptops are not the answer — the Enterprise plan’s org-level controls and SSO are. The two layers compose. Neither replaces the other.

    Managed settings also do nothing about an engineer who runs Claude Code on a personal machine outside MDM scope. That is a device management problem, not a Claude Code problem, and the fix is the same as it has always been: do not let unmanaged machines touch production code.

    The 30-Minute Rollout

    1. Pick one platform — start with whichever fleet is largest, usually macOS
    2. Write the minimum-viable managed-settings.json above
    3. Push it to one test machine via MDM, verify with claude config list
    4. Try three things the deny rules should block; confirm all three are blocked
    5. Roll to the rest of the fleet
    6. Set up the managed-settings.d/ directory so other teams can layer their own fragments without coordination

    The whole exercise is half a day of work for a platform engineer who already knows your MDM. The alternative is hoping every engineer reads the same Notion page about which commands not to run. Hope is not a security control.

    📖 Recommended Reading in Claude Code Insider

  • Claude Code for Teams: What to Commit, What to .gitignore, and What Actually Survives a Pull Request

    Claude Code for Teams: What to Commit, What to .gitignore, and What Actually Survives a Pull Request

    Last refreshed: May 15, 2026

    Most teams I see roll out Claude Code by handing every engineer the install command and walking away. Three weeks later, half the repo has personal preferences committed to .claude/settings.json, the other half has a CLAUDE.md that contradicts the actual review process, and someone’s customized subagent is silently making code changes nobody else on the team understands.

    There is a better way, and it lives in the split between three files: CLAUDE.md, .claude/settings.json, and .claude/settings.local.json. Get this split right, and Claude Code becomes a force multiplier for the team. Get it wrong, and you are shipping AI-generated code that nobody owns.

    The Three-File Split

    Here is the rule, no exceptions:

    CLAUDE.md — committed. Project root. Every engineer’s session reads this at startup. Put your architectural decisions, preferred libraries, naming conventions, and a review checklist here. If you would not write it on a whiteboard for a new hire, it does not belong here.

    .claude/settings.json — committed. Team-wide tool permissions, default models, and hooks. This is the file that keeps personal flagship-model enthusiasts from blowing through your team’s budget when claude-sonnet-4-6 would have done the job. If you let everyone default to claude-opus-4-7 for routine refactors, your monthly invoice will tell you about it.

    .claude/settings.local.json — gitignored. Personal preferences, individual MCP server configs, anything that varies by engineer. Add this line to your .gitignore on day one:

    .claude/settings.local.json

    If you do not, someone will commit credentials by Friday. Audit your existing repo right now: git log --all --full-history -- .claude/settings.local.json will surface any history that needs scrubbing.

    The mistake I see most often is teams committing settings.local.json because someone copied a tutorial that did not make the distinction clear. That copy-paste error is the single most common Claude Code rollout failure I have seen this year.

    Shared Subagents Are the Real Win

    Project subagents live in .claude/agents/ and they ship with the repo. This is where teams compound value. A subagent for security review, one for accessibility audits, one for SQL migration safety — defined once, used by every engineer, every PR.

    A subagent definition is a markdown file with YAML frontmatter and a system prompt. When you commit it, every teammate’s claude invocation can call it. The subagent inherits your CLAUDE.md context automatically, so you do not have to redefine the project’s coding standards inside each agent.

    Here is the trap: do not put twelve subagents in there on day one. Start with one. The team’s most painful repeated review task is the right candidate. Whatever takes a long time and pulls in multiple engineers per PR — that is your first subagent. After two weeks of using it, you will know whether the second one is worth defining.

    CLAUDE.md Is a Living Document, Not a Manifesto

    The longest CLAUDE.md files I see are the worst-performing. Engineers do not read 4,000-word context files, and neither does Claude in any useful way — at some point you are paying for tokens that just dilute the signal.

    The CLAUDE.md files that actually shape behavior are usually compact, structured around three things:

    1. What this codebase is and what it is not.
    2. The handful of rules that get a PR rejected — test coverage, naming, error handling, dependency policy.
    3. A pointer to where deeper documentation lives.

    If your CLAUDE.md has a “philosophy” section, delete it. If it has a “history of the project” section, delete it. The file is read every session — make every line earn its tokens.

    CI/CD: Run Claude Code on PRs, Not in Place of Reviewers

    The pattern that works in CI is automated triage, not automated approval. A GitHub Actions workflow that runs Claude Code on every PR to check for things humans miss — missing tests, secrets in logs, public APIs without docstrings — adds value. A workflow that approves and merges PRs adds liability.

    Anthropic’s official GitHub Actions integration handles the auth and runs Claude Code headlessly. The realistic use cases:

    • Comment on PRs with a structured review (not a merge gate).
    • Auto-label PRs based on the diff.
    • Flag suspected regressions before a human reviewer opens the PR.

    Avoid: anything that auto-merges, anything that posts directly to production-facing systems, anything that calls a paid API on every commit to a feature branch. The bill compounds quickly when CI fires Claude on every push to every developer branch. Gate the workflow on PR-target branches only, or on labels.

    Where Claude Code for Teams Loses Today

    The honest list:

    • No native role-based permissions inside a single repo. If you want a junior engineer’s Claude Code to be more restricted than a senior’s, you have to enforce it through settings.json and trust everyone to not edit it. The Enterprise plan adds SSO, SCIM, and audit logs at the workspace level, but inside the repo, Claude Code itself does not differentiate by role.
    • No first-class secret scanning before commits. Hooks can plug this gap, but you have to wire pre-commit yourself.
    • Shared MCP servers are still per-developer auth. A team-shared Linear or Jira MCP, for example, still requires each engineer to authenticate individually.

    The Team plan addresses workspace-level governance through Premium seats, which is the tier that actually unlocks Claude Code for teammates. The Enterprise plan layers on SSO, SCIM, and audit logs. Neither makes the in-repo configuration questions go away — those are still your team’s problem to solve.

    Model Selection Is a Team Decision

    This one matters more than people realize. Default everyone in .claude/settings.json to claude-sonnet-4-6 for day-to-day work, with claude-opus-4-7 available for explicitly hard tasks. The current Anthropic lineup as of this writing — flagship claude-opus-4-7, workhorse claude-sonnet-4-6, fast claude-haiku-4-5-20251001 — is documented at docs.anthropic.com/en/docs/about-claude/models, and the model strings change frequently enough that hard-coding them in scripts has bitten me twice this year. Read that page, do not memorize it.

    A team that defaults to flagship for everything and a team that defaults to workhorse with selective escalation will see meaningfully different invoices for substantially the same productivity. Make the choice consciously.

    The 20-Minute Setup

    If you are rolling Claude Code out to a team next week:

    1. Add .claude/settings.local.json to .gitignore. First commit, today.
    2. Write a focused CLAUDE.md covering review-blocking rules. Ship it short.
    3. Create one subagent in .claude/agents/ for the team’s most painful review task.
    4. Add a single GitHub Actions workflow that runs Claude Code on PRs in comment-only mode.
    5. Schedule a 30-minute team review of the CLAUDE.md every two weeks. Delete more than you add.

    That is it. Everything else is iteration. The teams that succeed with Claude Code treat the configuration as code — versioned, reviewed, and pruned. The teams that fail treat it as a personal productivity tool that happens to be in a shared repo.

    Decide which kind of team you want to be before the third engineer commits.

    📖 Recommended Reading in Claude Code Insider

  • We Published Hundreds of Articles About Claude — And Some of Them Were Wrong. Here’s Everything We’re Doing About It.

    We Published Hundreds of Articles About Claude — And Some of Them Were Wrong. Here’s Everything We’re Doing About It.

    Last refreshed: May 15, 2026

    I owe you an apology.

    Tygart Media has been publishing about Claude — Anthropic’s AI model — for months. We’ve written about its capabilities, its pricing, its API strings, how to use it, why it matters. We positioned ourselves as a resource for people who want to understand and use Claude intelligently.

    And some of what we published was wrong.

    Not intentionally. Not carelessly in the moment. But wrong in the way that happens when you’re moving fast, publishing at scale, and not building the right systems to catch your own errors. Model version numbers were stale. Pricing figures were outdated. API strings referenced models that had been retired. If you used our content to make a decision about Claude — about which model to use, what to pay, how to call the API — some of that information may have led you in the wrong direction.

    That’s unacceptable to me. And I want to tell you exactly what happened, exactly what I found, and exactly what I’ve built to make sure it never happens again.

    How We Found Out

    It didn’t start with our own discovery. It started with a message.

    Kristin Masteller, the General Manager of Mason County PUD No. 1, reached out on LinkedIn to flag inaccuracies in our local coverage — a different set of articles, but the same underlying problem: we had published with confidence about things we hadn’t verified carefully enough.

    That message hit differently than a normal correction request. Because it made me ask a harder question: if our local coverage had errors, what about our Claude coverage? We had 200+ posts. We were publishing multiple times per day. We had never built a systematic quality check.

    So we ran one.

    The Audit: What We Found

    We wrote a scanner that pulled every post from tygartmedia.com and ran each one through a quality gate checking for four categories of errors:

    • Category A: Stale model names (e.g., “Claude Haiku” with no version number, or references to Claude 3 models as current)
    • Category B: Wrong pricing (e.g., Haiku priced at $0.80/MTok when the actual price is $1.00/MTok)
    • Category C: Deprecated feature claims (features or behaviors that no longer apply)
    • Category D: Cross-site contamination (content from other publication contexts bleeding into Claude coverage)

    Out of 2,333 total posts on the site, 701 touched Claude or AI topics. Of those, 65 posts had violations — 121 individual errors in total.

    We auto-corrected 28 posts immediately — wrong model strings, wrong pricing, outdated API references. 18 posts with more complex issues are still flagged for human review. We are working through them.

    I’m not sharing this to perform humility. I’m sharing it because you deserve to know the scope of the problem, and because the methodology for finding it might be useful to you.

    What We Built to Fix It

    The audit was a one-time fix. What we actually needed was a system — something that would catch these errors before they went live, and keep our model information current automatically.

    Here’s what we built:

    1. The Claude Intelligence Desk

    A dedicated Notion page that serves as the single source of truth for all Claude model information across our entire content operation. It contains the current model truth table — every model name, API string, input/output price, context window, and status — verified against Anthropic’s live documentation.

    The rule is simple: before anyone writes, edits, or publishes any article that mentions Claude, they check this page. If the “Last Verified” timestamp is more than 12 hours old, they run a refresh before proceeding.

    2. The Claude Intelligence Scanner (Automated, Twice Daily)

    A scheduled task that runs at 6 AM and 6 PM Pacific every day. It fetches Anthropic’s models documentation page, compares the current model table to what’s in our Notion desk, and if anything has changed — a new model, a price change, a deprecation — it updates the desk automatically and flags it for human review.

    We will never again be caught publishing outdated Claude information because a model changed and we didn’t notice.

    3. Pre-Publish Quality Gates

    Every new Claude article now runs through the quality gate categories above before it goes live. Wrong model string → blocked. Outdated pricing → blocked. Deprecated claim → flagged.

    4. The Fix Log

    Every correction we make is logged with the post ID, the original wrong content, the correct replacement, and the date. Accountability in writing, not just in words.

    Why I’m Telling You All of This

    Because I think the way most AI content operations work is broken — and I think transparency about that is more useful than pretending we had it figured out.

    The standard playbook for AI content is: write fast, publish often, stay ahead of the news cycle. The problem is that AI — and especially Claude — moves so fast that “write fast” and “stay accurate” are genuinely in tension. Models change. Prices change. Features get added, deprecated, retired. If you’re not building systems to track that, you’re going to drift.

    We drifted. We caught it. We fixed it. And now I want to open up everything we built.

    The Claude Intelligence Desk methodology, the quality gate framework, the scanner architecture — I’m making all of it available. If you’re publishing about Claude, if you’re building automations around Claude, if you’re running a content operation that touches Anthropic’s ecosystem in any way, you can use what we built. Adapt it. Improve it. Tell me what I got wrong in the system design.

    This is not a product. This is not a lead magnet. It’s just the actual work, shared openly, because that’s how we get better together.

    I Want to Build This With You

    Here’s what I’ve learned from this process: the people who catch errors fastest are the people closest to the technology. The developers who are actually calling the API. The builders running Claude in production. The researchers who read every Anthropic paper when it drops. The people in Singapore, India, the UK, Europe, Brazil — every region where Claude is being adopted rapidly and where the local context matters.

    I don’t have all of that knowledge. No single publication does.

    So I’m opening this up.

    If you use Claude seriously — if you’re building with it, writing about it, researching it, deploying it — I want you to write with us.

    What that looks like:

    • Writers and researchers: You bring the knowledge and the perspective. We provide the platform, the distribution, the SEO infrastructure, and editorial support. Your byline, your voice, your expertise.
    • Builders and developers: You’re running Claude in production. You know what actually works, what breaks, what the documentation doesn’t tell you. Write that. The practitioner perspective is the most valuable thing we can publish.
    • International voices: What does Claude adoption look like in Singapore right now? What’s the conversation in India’s developer community? How are European companies thinking about AI compliance alongside Claude? These are stories we cannot tell without you — and they’re stories our audience desperately needs.
    • Correctors: If you read something on this site that’s wrong, tell us. We have a system now. We will fix it, log it, and credit you if you want the credit.

    This is not about content volume. We publish enough already. This is about getting it right — and getting perspectives we genuinely don’t have.

    How to Get Involved

    If any of this resonates — if you want to write, contribute, correct, or just have a conversation about where Claude is going — reach out directly: will@tygartmedia.com

    Tell me where you are, what you’re building or writing or researching, and what you’d want to say if you had a platform to say it. No formal application. No content calendar to fit into. Just a conversation.

    We’re also building out a formal contributor program at tygartmedia.com/contribute/ — trade affiliates, community writers, featured contributors. If that’s more your speed, start there.

    But honestly? Just email me. Let’s figure out what makes sense.

    The work continues. The scanner runs twice a day. The quality gates are live. And if you find something wrong on this site — about Claude, about anything — I genuinely want to know.

    That’s the standard I should have been holding from the beginning. We’re holding it now.

    — Will Tygart
    Tygart Media

    📖 Recommended Reading in Claude Code Insider