Skip to main content

Overview

The Fiddler Claude Code Plugin (fiddler-coding-agent-plugin, named fiddler-claude-code-plugin before version 0.7.0) instruments Claude Code sessions and delivers per-turn OpenTelemetry traces to Fiddler. It runs as a set of Claude Code hooks (a small binary that fires on session events) and captures each turn as a nested trace with the user prompt, LLM response content, tool input/output, and token usage. Plugin traces group into the same Fiddler session as native Claude Code traces, so the two can be used together. The plugin is open source under the Apache 2.0 license. Its source code, releases, and marketplace live in the fiddler-labs/fiddler-coding-agent-plugin GitHub repository.
This capability is currently in public preview. It is available to every customer and Fiddler responds promptly to issues, but it is not yet covered by an SLA and its APIs may still change.
The plugin fails open: a hook error, a missing binary, or an unreachable endpoint never breaks or slows your Claude Code session. At worst, a turn’s trace is skipped.

Prerequisites

  • A supported platform, on x64 or ARM64:
  • Claude Code 2.1.120 or later. Full trace capture depends on hooks and payload fields introduced across the 2.1.x line, the most recent being the duration_ms tool-timing field added in 2.1.119. On older versions the plugin fails open, capturing less rather than breaking your session.
  • curl or wget, and sha256sum or shasum. At least one tool from each pair is preinstalled on macOS (which includes curl and shasum) and most Linux distributions, and Git for Windows includes curl and sha256sum. The plugin downloads its binary from the repository’s public GitHub Release over HTTPS and installs it only after verifying its SHA-256 checksum.
  • Outbound HTTPS access to github.com and release-assets.githubusercontent.com from each machine that runs the plugin. GitHub redirects release downloads from github.com to a separate release-asset host (currently release-assets.githubusercontent.com), so a proxy or firewall must allow both.
  • A Fiddler GenAI application, with its application ID and an API key.

Windows Support

Windows support is in preview.
  • Git for Windows is required. Claude Code runs plugin hooks through Git Bash when Git for Windows is installed. Without it, Claude Code runs hooks through PowerShell, the plugin’s hooks do not start, and no traces are sent.
  • The Windows binary is not yet code-signed. Like every release binary, it is downloaded from the repository’s GitHub Release and checked against the release’s SHA-256 checksums before it runs. Strict application-control policies (such as AppLocker, App Control for Business, or Smart App Control) or endpoint security tools may still block an unsigned program in the user’s profile directory. If that happens, the plugin sends no traces, but Claude Code keeps working normally.
  • Binary location. The binary is cached as on-event-windows-<arch>-<version>.exe, where <arch> is amd64 (x64) or arm64, in the bin folder of the plugin’s data directory (CLAUDE_PLUGIN_DATA), as on macOS and Linux. Use this location if you need an application-control exception.

Installation

1

Add the marketplace

2

Install the plugin

3

Configure and activate

Provide the configuration values: fill in the dialog that the install opens, or use one of the other methods described below. The plugin activates on install; if Claude Code prompts you to, run /reload-plugins to apply it without restarting. The plugin downloads its binary on the first session.
The binary is downloaded once per version and cached, so the first session after installing (or upgrading) does the download and later sessions reuse it.

Upgrading

New versions are published to the marketplace repository. Third-party marketplaces do not auto-update by default, so upgrades are manual. To move to a newer version, re-run the install command; it refreshes the marketplace and installs the latest version:
1

Update the plugin

Optionally refresh the marketplace first with /plugin marketplace update fiddler-plugins, though the install command already does this.
2

Activate the new version

Run /reload-plugins if Claude Code prompts you; no restart is needed. On the next session the plugin downloads the binary matching the new version, verifies its checksum, and caches it.
Check the installed version any time with /plugin list. See the plugin changelog for what changed in each version.
Each new version downloads a new binary, so upgrading needs the same HTTPS access to github.com and release-assets.githubusercontent.com as the first install.

Migrating to the New Plugin ID

In version 0.7.0 the plugin was renamed from fiddler-claude-code-plugin to fiddler-coding-agent-plugin. When you update from an earlier version, Claude Code moves your enabled state and the OTLP_URL and APP_ID values to the new plugin ID automatically. Your saved auth token is not moved, so after updating:
1

Install under the new ID if needed

If Claude Code reports that the plugin is not cached, run the install command once:
2

Re-enter the auth token

If you configured the plugin only through "env", skip this step: the CLAUDE_PLUGIN_OPTION_* variable names do not include the plugin ID. Also skip it if your organization supplies the auth token through managed settings: a token entered here is stored in Claude Code’s secure credential storage and overrides the managed value.
3

Update managed settings

If your organization supplies the options through managed settings, update the plugin ID in enabledPlugins and pluginConfigs. Claude Code does not rewrite managed settings.
4

Update service.name filters

Plugin traces now report service.name as fiddler-coding-agent-plugin instead of fiddler-claude-code-plugin. Update any dashboards, filters, or alerts that match on the old value.

Configuration

The plugin needs three options. All three must be set for the plugin to send traces. When the plugin is installed or enabled from /plugin, Claude Code opens a configuration dialog for any option that is not already set. Provide the values in one of the following ways. Configuration values are read when a session starts, so start a new Claude Code session after changing any of them.

Individual Users

Fill in the dialog that /plugin install opens, or install from your shell with the values supplied up front. claude plugin install never prompts:
To change values later, run /plugin configure fiddler-coding-agent-plugin@fiddler-plugins in Claude Code.

Organization Rollout

Administrators can supply every option in Claude Code managed settings. The plugin is then installed and enabled automatically, and users are not prompted. If your organization already delivers managed settings from the claude.ai admin console or through MDM, add these keys there: by default Claude Code reads only one managed source and ignores managed-settings.json when a higher-ranked source is present. If the plugin doesn’t appear, check the Setting sources line in /status.
Default managed-settings file locations:
  • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
  • Linux and WSL: /etc/claude-code/managed-settings.json
  • Windows: C:\Program Files\ClaudeCode\managed-settings.json
  • The managed-settings file holds the API key in plain text. Use a key scoped to the plugin’s Fiddler application, and restrict access to the file.
  • If a user previously entered an auth token in the configuration dialog, that token is kept in Claude Code’s secure credential storage and overrides the managed value. Have the user uninstall and reinstall the plugin to clear it.

Settings File (env)

You can also set the options as environment variables under "env" in your Claude Code settings, either ~/.claude/settings.json (user-level) or .claude/settings.local.json (project-level):
Values under "env" are used only for options that have no stored value from the dialog, --config, or managed settings (see How Values Are Resolved). They also do not stop Claude Code from opening the configuration dialog when you install or enable the plugin. To avoid the prompt, use --config or managed settings.
Do not commit your API key. For project-level configuration use .claude/settings.local.json (git-ignored by default) rather than a committed settings.json.

How Values Are Resolved

The plugin receives one value per option. When an option is set in more than one place, the highest-priority source wins: In practice:
  • "env" is a fallback. If a user later fills in the dialog, the dialog values take over.
  • Managed settings override the endpoint and application ID that users enter, so administrators control them centrally. The exception is an auth token a user already entered in the dialog, as described in Organization Rollout.

Verify Configuration

To check which options Claude Code has stored, run this from your shell:
The unconfigured list should be empty. This command reports only stored values, so if you configured the plugin only through "env", all three options appear as unconfigured even though tracing works.

Optional Settings

Set these under "env" in your Claude Code settings, or export them in the shell that launches Claude Code:

What You Get

Each user turn produces one trace in Fiddler, nested under a root agent span, with:
  • The user prompt and the assistant’s response for the turn.
  • One LLM span per model call, with token usage (including cache tokens), model, and finish reason.
  • One tool span per tool call, with the tool name, arguments, and result, plus the permission decision for the call.
  • Error, refusal, and interrupt outcomes marked on the relevant spans.
Because the plugin stamps the Claude Code session ID on every span, a session’s turns group into a single Fiddler session with no extra configuration. Once traces arrive, you can score them with Fiddler evaluators. Because the plugin captures both input and output content, evaluators that need the response (such as faithfulness) can run on these traces.

Data Capture and Privacy

In the current preview build the plugin always captures prompt, response, and tool input/output content. Content-redaction controls are not yet enforced. Deploy the plugin only where capturing this content is acceptable, and scope the Fiddler application and API key accordingly. To limit the developer identity that accompanies traces, set FIDDLER_OMIT_USER_INFO=true.
Apart from downloading its binary from the GitHub Release (see Prerequisites), the plugin makes only outbound OTLP/HTTP calls to your configured Fiddler endpoint, and never logs the auth token. Where the token is stored depends on how you configure it: a token entered in the dialog or with --config is stored in Claude Code’s secure credential storage, while a token in managed settings or under "env" is stored in plain text in that settings file. Restrict access to any file that holds the token.

Troubleshooting

No Plugin Traces Appearing in Fiddler

  1. After installing or upgrading, make sure the plugin is active (run /reload-plugins if Claude Code prompts you), and confirm the machine can download the binary: curl or wget is installed, sha256sum or shasum is installed, and both github.com and release-assets.githubusercontent.com are reachable over HTTPS. To test the full download path, fetch a release file and follow its redirect, replacing <version> with the installed version shown by /plugin list:
    If this fails, allow both hosts through your proxy or firewall. If the download fails or the checksum does not match, the plugin does not install the binary and skips tracing for that session.
  2. On Windows, confirm that Git for Windows is installed and that no application-control policy or endpoint security tool is blocking the plugin’s binary (see Windows Support).
  3. Confirm all three options are set, as described in Verify Configuration. If you configured the plugin through "env", check the three CLAUDE_PLUGIN_OPTION_* values instead. If any option is empty, the plugin sends nothing.
  4. Confirm APP_ID is a valid application ID; Fiddler drops spans without one.
  5. Confirm the auth token is the bare token, with no Bearer prefix.
  6. If traces stopped after upgrading from a version earlier than 0.7.0: if you entered the auth token in the configuration dialog or with --config, re-enter it under the new plugin ID; if your organization uses managed settings, confirm that the plugin ID was updated there. Also check any service.name filters (see Migrating to the New Plugin ID).

Some Turns Are Missing Token Usage or the Response

Turns that were interrupted, or that were in flight when the session ended, are recovered with the prompt but without token usage or response text, which are available only when a turn completes normally.