Setup & Configure
The CLI is served by your Shield360 platform. Get the install key from Visibility → Setup:
curl -fsSL https://app.shield360.ai/api/cli/install.sh | SHIELD360_INSTALL_KEY=<key> sh$env:SHIELD360_INSTALL_KEY = "<key>"iwr -useb https://app.shield360.ai/api/cli/install.ps1 | iexReplace app.shield360.ai with your own address if you self-host. The script installs to ~/.shield360/bin/shield360 (%USERPROFILE%\.shield360\bin\shield360.exe on Windows), enrols the machine, and installs hooks for every coding agent it finds, so the next step is only needed for agents installed later. Coding-agent telemetry is then sent through the machine’s own collector token, and no platform API key is needed on the machine. See Deploy the collector.
shield360 coding install writes the right hook config for the agent you pass and is fully idempotent. You can also point at the plugin marketplace (plugins/ in the Shield360 distribution) and let the agent pull the manifest itself, or invoke the agent through shield360 coding launch which auto-installs and execs.
# One-time installshield360 coding install --vendor=claude-code
# Or run Claude Code through the launcher (auto-installs)shield360 coding launch claude-codeManifest path: ~/.claude/plugins/shield360-cc/. Hooks wired: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, SubagentStop, SessionEnd. Claude Code’s transcript JSONL (transcript_path in the hook payload) is tailed on SessionStart for early model attribution and on SessionEnd for authoritative token usage and cost.
Optional: Claude Code’s native OpenTelemetry exporter. If you’d rather not install the plugin, or you want a second signal source for cross-checking, you can point Claude Code’s built-in OTel exporter at your Shield360 collector instead. Both paths can run side by side - Shield360 dedupes per session.id (Claude Code’s authoritative cost/tokens from the native path win, while the hook path provides the repository/working-folder context that Claude Code itself can’t see).
export CLAUDE_CODE_ENABLE_TELEMETRY=1export OTEL_METRICS_EXPORTER=otlpexport OTEL_LOGS_EXPORTER=otlpexport OTEL_EXPORTER_OTLP_PROTOCOL=grpcexport OTEL_EXPORTER_OTLP_ENDPOINT=$SHIELD360_OTLP_ENDPOINTexport OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer $SHIELD360_API_KEY"# Optional: also enable traces (beta - gives per-tool / per-LLM-turn spans)export CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1export OTEL_TRACES_EXPORTER=otlpSee Claude Code’s monitoring docs for the full environment-variable surface (managed settings, dynamic headers, cardinality controls, content-capture gates). When both paths are active, Shield360 folds them into one chat thread automatically.
shield360 coding install --vendor=cursorManifest path: ~/.cursor/hooks.json (user scope - applies to every workspace you open in Cursor; works the same on macOS, Linux, and Windows). All Cursor hook events (sessionStart/End, prompt/response/thought, tool + shell + MCP phases, subagent lifecycle, file edits, preCompact) invoke shield360 coding hook --vendor=cursor --event=<name> directly. At install time the shield360 token in each command is rewritten to the absolute path of the CLI binary that ran shield360 coding install, which sidesteps the minimal-PATH that GUI-launched Cursor windows inherit on macOS and Linux, and makes the same manifest work on Windows where there is no shell wrapper.
shield360 coding install --vendor=codexManifest path: ~/.codex/plugins/shield360/. Hooks wired: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop. Codex scopes every hook to a turn_id so we emit one coding_agent.llm.turn span per turn (built on Stop), with the prompt, last-assistant message, and the per-tool calls produced during that turn folded into the OTel-canonical gen_ai.input.messages / gen_ai.output.messages envelopes.
The CLI tails ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl on Stop to compute the per-turn token delta (input, output, cached, reasoning) from Codex’s running token_count events, so cost rollups in Shield360 reflect the same per-turn deltas Codex itself records.
Subagent linkage is read from the transcript’s session_meta record at SessionStart; child turns inherit coding_agent.agent.parent_id automatically so the UI folds them under the spawning chat. Codex doesn’t expose a SessionEnd event, so the session row updates incrementally as each Stop lands.
If codex features list doesn’t already enable codex_hooks on your build, add this to ~/.codex/config.toml:
[features]codex_hooks = true
[plugins."shield360"]enabled = trueOlder Codex builds use hooks = true and plugin_hooks = true instead of codex_hooks.
Run any short coding-agent session, then refresh the Agents page in your Shield360 UI. You should see a new row labelled with the vendor and a “Coding” badge. Click in for the dedicated Overview / Sessions / Users tabs.
Configure
Section titled “Configure”Everything below is a setting you can change at any point after setup - none of it needs to happen up front.
Endpoint, API key, and content capture
Section titled “Endpoint, API key, and content capture”The fastest path is shield360 configure - it answers the same questions a CI / Helm chart would set via env. The result is written to ~/.config/shield360/config.env (Linux/macOS) or %APPDATA%\shield360\config.env (Windows). For headless / fleet rollouts, prefer env vars or flags directly - they take precedence over the file (flags > env > config file).
shield360 configure \ --endpoint https://shield360.example.com:4318 \ --api-key $SHIELD360_API_KEYEquivalent environment variables (precedence: flags > env > config file):
| Variable | Purpose |
|---|---|
SHIELD360_OTLP_ENDPOINT | OTLP/HTTP endpoint of your collector |
SHIELD360_API_KEY | Authenticates the OTLP exporter |
SHIELD360_USER | Optional override for gen_ai.user.name (email or login) |
SHIELD360_CODING_CONTENT_CAPTURE | minimal | metadata_only | full (default: full) - see Privacy & Governance |
Standard OTEL_EXPORTER_OTLP_* variables are honoured as fallbacks so existing OTel users can reuse their setup. Re-run shield360 configure (or update the env vars) any time - changes apply to the next session, no reinstall of the vendor hooks needed.
Stop tracking / uninstall
Section titled “Stop tracking / uninstall”The inverse of shield360 coding install. Removes the per-vendor host plugin manifests written by install, deregisters the plugin from the vendor’s own CLI where applicable (Claude Code, Codex), and leaves your shared config alone by default so you can re-onboard without re-entering credentials.
shield360 coding uninstall --vendor=cursor # one vendorshield360 coding uninstall --vendor=all # every vendor at onceshield360 coding uninstall --vendor=all --purge # also drop ~/.config/shield360 + session-state cacheshield360 coding uninstall --vendor=cursor --dry-run # preview without touching diskWhat each flag removes:
| Path | Removed by --vendor=<v> | Removed by --purge |
|---|---|---|
~/.claude/plugins/shield360-cc/ | ✓ (when <v> is claude-code or all) | - |
~/.local/share/shield360/claude-marketplace/ | ✓ (when <v> is claude-code or all) | - |
shield360 entries in ~/.cursor/hooks.json (other tools’ entries preserved; file deleted if it ends up empty) | ✓ (when <v> is cursor or all) | - |
~/.local/share/shield360/codex-marketplace/ | ✓ (when <v> is codex or all) | - |
claude plugin uninstall shield360-cc@shield360 | ✓ best-effort | - |
codex plugin remove shield360@shield360 + codex plugin marketplace remove shield360 | ✓ best-effort | - |
~/.config/shield360/ (your configure output) | - | ✓ |
<UserCacheDir>/shield360/sessions/ (session-state cache) | - | ✓ |
The shield360 binary itself is not touched. Uninstall it the way you installed it:
brew uninstall shield360 # Homebrewrm ~/.shield360/bin/shield360 # curl|sh installerrm $(go env GOPATH)/bin/shield360 # go installIf you only want to pause a vendor temporarily rather than uninstall it, re-run shield360 coding install --vendor=<v> later - it’s idempotent and will re-wire the same manifest.
Troubleshooting
No row showing up, or hooks running with no spans landing? Start here.