datex-studio-cli 0.4.16__tar.gz → 0.4.18__tar.gz

datex_studio_cli-0.4.18/CONTEXT.md

@@ -0,0 +1,13 @@
+# Datex Studio CLI
+
+The command-line interface (`dxs`) through which LLM agents and humans work with the Datex Studio low-code platform, plus the client side of its server counterpart, Quartermaster.
+
+## Language
+
+**Quartermaster**:
+The Datex-owned service that is the dxs CLI's server-side counterpart — it issues supplies (skills, context) and keeps the records (telemetry, config index).
+_Avoid_: companion service, dxs backend, dxs service
+
+**Endpoint family**:
+A cohesive group of Quartermaster endpoints serving one CLI capability (telemetry ingest, feedback, skills distribution, OData proxy, config indexing, context store). The unit in which Quartermaster is composed, enabled, and — when one earns it — deployed separately.
+_Avoid_: module, microservice, subsystem

{datex_studio_cli-0.4.16 → datex_studio_cli-0.4.18}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: datex-studio-cli
-Version: 0.4.16
+Version: 0.4.18
 Summary: CLI for Datex Studio low-code platform, designed for LLM-based AI agents
 Project-URL: Homepage, https://github.com/datex/datex-studio-cli
 Project-URL: Documentation, https://github.com/datex/datex-studio-cli
@@ -761,6 +761,7 @@ dxs api PUT /some/endpoint '{"data": "value"}'
 ### For Human Users
 
 - **[Analysis Workflow](docs/analysis-workflow.md)** - Bulk analysis workflow documentation
+- **[Claude Code Telemetry Collector](otel/README.md)** - Team-wide Claude Code observability: OTel collector → Datadog, rolled out from the claude.ai admin console
 
 ## Development
 

{datex_studio_cli-0.4.16 → datex_studio_cli-0.4.18}/README.md

@@ -708,6 +708,7 @@ dxs api PUT /some/endpoint '{"data": "value"}'
 ### For Human Users
 
 - **[Analysis Workflow](docs/analysis-workflow.md)** - Bulk analysis workflow documentation
+- **[Claude Code Telemetry Collector](otel/README.md)** - Team-wide Claude Code observability: OTel collector → Datadog, rolled out from the claude.ai admin console
 
 ## Development
 

datex_studio_cli-0.4.18/otel/.env.example

@@ -0,0 +1,14 @@
+# Copy to .env and fill in. .env is gitignored -- never commit the real key.
+#
+# Datadog ingest API key (Organization Settings > API Keys).
+DD_API_KEY=your-datadog-api-key-here
+
+# Datadog site for your org. The Datex org is US1 - East, which is datadoghq.com.
+# DatexCorp is US3 - West, which would be us3.datadoghq.com.
+DD_SITE=datadoghq.com
+
+# Bearer token Claude Code clients must present (their
+# OTEL_EXPORTER_OTLP_HEADERS must carry the same value). The default below
+# matches local-test-settings.json for local runs; for Azure generate a strong
+# secret (e.g. `openssl rand -hex 32`) and store it as a container secret.
+OTLP_BEARER_TOKEN=local-dev-token

datex_studio_cli-0.4.18/otel/Dockerfile

@@ -0,0 +1,24 @@
+# OpenTelemetry Collector for Claude Code telemetry -> Datadog.
+#
+# The Datadog exporter lives only in the "contrib" distribution, not the core
+# collector image.
+#
+# NOTE: pin this tag to a tested version (or a digest) before deploying to
+# Azure. `latest` is fine for local verification, not for the team.
+#
+# Registry is fully qualified: podman does not default to Docker Hub for
+# unqualified names, so a bare `otel/...` prompts or fails there.
+FROM docker.io/otel/opentelemetry-collector-contrib:latest
+
+# Copied to an explicit path so the config location never depends on the
+# image's default, which differs between distributions. chown to the image's
+# built-in non-root user so readability never depends on checkout file modes.
+COPY --chown=10001:10001 collector-config.yaml /etc/otel/config.yaml
+
+# 4318: OTLP http/protobuf (all Claude Code speaks).
+# 13133: health_check extension, for orchestrator liveness/readiness probes.
+EXPOSE 4318 13133
+
+# DD_API_KEY, DD_SITE and OTLP_BEARER_TOKEN are supplied at runtime, never
+# baked into the image.
+CMD ["--config=/etc/otel/config.yaml"]

datex_studio_cli-0.4.18/otel/README.md

@@ -0,0 +1,174 @@
+# Claude Code telemetry → Datadog
+
+Centralised Claude Code observability for the team: an OpenTelemetry Collector holds the
+Datadog credential, developer machines hold none, and configuration is pushed from the
+claude.ai admin console rather than set up per-laptop.
+
+```
+Claude Code (each dev)  --OTLP/http-->  Collector (Azure)  --datadog exporter-->  Datadog
+        ^                                     ^
+        |                                     |
+ server-managed settings              DD_API_KEY lives only here
+ (claude.ai admin console)
+```
+
+## Files
+
+| File | Purpose |
+|---|---|
+| `Dockerfile` | Collector image (contrib distribution — the Datadog exporter is not in core) |
+| `collector-config.yaml` | Receivers, processors, Datadog exporter for logs + traces + metrics |
+| `docker-compose.yml` | Local verification harness |
+| `.env.example` | Template for `DD_API_KEY` / `DD_SITE` / `OTLP_BEARER_TOKEN` — copy to `.env` (gitignored) |
+| `remote-settings.json` | Payload for the claude.ai admin console |
+| `local-test-settings.json` | Same env block pointed at `localhost` for local testing |
+| `apply-local-cache.js` | Loads `local-test-settings.json` into Claude Code's settings cache for a local test run |
+
+## Verify locally
+
+```bash
+cd otel
+cp .env.example .env          # fill in DD_API_KEY
+docker compose up --build
+```
+
+Then load the settings and restart:
+
+```bash
+node apply-local-cache.js      # writes ~/.claude/remote-settings.json, checks the collector
+                               # --revert restores it to {}
+```
+
+**Restart Claude Code immediately afterwards.** Two reasons: OpenTelemetry configuration is
+only read at startup, and Claude Code refetches server-managed settings in the background —
+when the org has no server-side config that refetch overwrites the cache with `{}`. A
+hand-placed payload therefore survives exactly one session and must be re-applied before
+each restart. Approve the `OTEL_EXPORTER_OTLP_ENDPOINT` dialog on startup or Claude Code
+exits.
+
+This one-session-per-edit friction disappears once the payload is delivered from the admin
+console for real.
+
+Confirm in Datadog under **Logs** (not APM) with `service:claude-code`. Collector-side, the
+`debug` exporter prints per-batch item **counts** to container stdout — enough to confirm
+data is flowing. It deliberately does not print payloads; see the verbosity note in
+`collector-config.yaml` before raising it:
+
+```bash
+docker compose logs -f otel-collector
+```
+
+## Hand off to the team
+
+1. **Decide the data-governance posture first** (see the Data governance section below):
+   keep or drop `OTEL_LOG_TOOL_CONTENT` in `remote-settings.json` *before* anything ships.
+   Raw API bodies (`OTEL_LOG_RAW_API_BODIES`) are already off; prompts, responses and tool
+   content still land in Datadog.
+2. Pin the base image in `Dockerfile` to a tested tag or digest — it currently says
+   `latest`. Then build and push to ACR, deploy as an Azure Container App or App Service.
+   Give the container an explicit memory limit and set `GOMEMLIMIT` to ~80% of it — the
+   `memory_limiter` processor depends on a real limit (`docker-compose.yml` shows the
+   pattern). Point liveness/readiness probes at the `health_check` extension on port 13133.
+3. Terminate TLS in front of it. **OTLP payloads carry full prompts, file contents and
+   responses** — this must not travel over plain HTTP. The endpoint pushed to clients is
+   the TLS front-end URL (Azure Container Apps ingress listens on 443), not `:4318` —
+   ingress targets the collector's internal 4318.
+4. Set `DD_API_KEY`, `DD_SITE` and `OTLP_BEARER_TOKEN` as container secrets, not image
+   layers. Generate the token with e.g. `openssl rand -hex 32`.
+5. Restrict ingress to corporate network / VPN. The bearer token the receiver now requires
+   is defense in depth on top of that — a shared, developer-visible secret, not a
+   substitute for network restriction.
+6. An Owner pastes `remote-settings.json` into
+   **claude.ai → Admin Settings → Claude Code → Managed settings**, replacing
+   `<COLLECTOR-PUBLIC-URL>` and `<OTLP-BEARER-TOKEN>`.
+
+Each developer sees a **one-time approval dialog** for the endpoint variable. If they
+decline, Claude Code exits. This is unavoidable — Claude Code always prompts for a
+non-empty `OTEL_EXPORTER_OTLP_ENDPOINT`.
+
+## Where prompts and responses land
+
+Verified against Claude Code 2.1.220 through this collector. **Both prompts and response
+text are captured.**
+
+| Content | Attribute | Event |
+|---|---|---|
+| Prompt text | `prompt_text` | `user_prompt` |
+| Prompt uuid | `prompt.id` | all events |
+| Assistant response text | `response`, `response_length` | `assistant_response` |
+| Tool calls / inputs | `tool_input`, `tool_parameters` | `tool_result` |
+| Cost / tokens | `cost_usd`, `input_tokens`, `output_tokens` | `api_request` |
+| Thinking | `content[].thinking` | always `<REDACTED>` |
+
+### Why the collector is required, not just convenient
+
+Sending straight to Datadog's OTLP intake (`https://otlp.datadoghq.com`) loses data. Two
+separate defects, both fixed here:
+
+**1. Prompt text destroyed by an attribute collision.** Claude Code emits `prompt` (the
+text) *and* `prompt.id` (a uuid). Datadog flattens dotted keys into nested objects, so
+`prompt.id` becomes an object at `prompt` and the sibling string is silently discarded —
+`prompt_length` still reports the real size, which is how we caught it. The `transform`
+processor in `collector-config.yaml` copies the string to `prompt_text` and drops the
+colliding key.
+
+Slash-command prompts were never affected, because command dispatches carry no `prompt.id`
+and therefore no collision. That asymmetry — "prompt text only shows up for slash
+commands" — is the signature of this bug.
+
+**2. `assistant_response` events dropped in transit.** With the direct endpoint these never
+arrived, across hours of querying. Through the collector they arrive with a populated
+`response` attribute. Same flags, same client version — the only change was the endpoint,
+so Datadog's OTLP intake appears to drop them. The collector's `datadog` exporter forwards
+them intact.
+
+### Query gotchas
+
+- **`prompt_length` without `prompt_text`** means the transform isn't running — that is the
+  collision, not redaction.
+- **Search by attribute, not free text.** `@marker:VALUE` works; a bare string only matches
+  the log message body, which is usually just the event name.
+- **No `api_request_body` / `api_response_body` events** — `OTEL_LOG_RAW_API_BODIES` is
+  deliberately off: request bodies repeat the whole conversation on every API call (pure
+  ingest cost, plus one more copy of any secret in context), and `user_prompt` +
+  `assistant_response` + the tool events already reconstruct the transcript. If raw bodies
+  are ever needed, re-enable the flag in `remote-settings.json` and note request bodies
+  arrive truncated at the 60 KB `CLAUDE_CODE_OTEL_CONTENT_MAX_LENGTH` limit (invalid
+  JSON — filter on `body_truncated`).
+
+A `Stop` hook reading `last_assistant_message` is **not needed**. That was a workaround
+built before `assistant_response` was confirmed working through the collector. An
+implementation is kept at `~/.claude/hooks/dd-transcript.js` (Delian's machine,
+unregistered) but is not part of this setup.
+
+## Enforcement reality check
+
+Server-managed settings are, per Anthropic's docs, "a client-side control, not a security
+boundary. On unmanaged devices, a user doesn't need admin or sudo access to bypass them."
+
+| Bypass | Effect |
+|---|---|
+| Delete `~/.claude/remote-settings.json` | Brief unenforced window at next start |
+| Run an older Claude Code | Never fetches managed settings |
+| Set `ANTHROPIC_BASE_URL` or `CLAUDE_CODE_USE_BEDROCK` | Settings fetch skipped entirely |
+
+`forceRemoteSettingsRefresh` and `requiredMinimumVersion` (both already in
+`remote-settings.json`) close the easy gaps. For genuine enforcement, deploy
+endpoint-managed settings by MDM to `C:\Program Files\ClaudeCode\managed-settings.json`
+— note that `C:\ProgramData\ClaudeCode\` stopped being read in v2.1.75.
+
+**Server-managed and endpoint-managed settings do not merge.** If server-managed delivers
+any keys at all, the MDM file is ignored completely. Pick one as the source of truth.
+
+## Data governance
+
+With these flags on, Datadog receives prompts, responses, and tool inputs and outputs —
+including the contents of any file Claude Code reads. In `datex-application-api` that means
+connection strings and `Azure__ClientSecret` can land in Datadog logs. Every event also
+carries the developer's email and account UUIDs. (Raw API bodies —
+`OTEL_LOG_RAW_API_BODIES` — are deliberately off: they would re-send the whole conversation
+on every API call for no analytical gain.)
+
+Decide deliberately whether that is acceptable before rolling out, and consider dropping
+`OTEL_LOG_TOOL_CONTENT` if it is not. Datadog's Sensitive Data Scanner can redact patterns
+at ingest as a second layer.

datex_studio_cli-0.4.18/otel/apply-local-cache.js

@@ -0,0 +1,88 @@
+#!/usr/bin/env node
+/**
+ * Local testing helper.
+ *
+ * Copies local-test-settings.json into Claude Code's server-managed settings
+ * cache (~/.claude/remote-settings.json), simulating a policy pushed from the
+ * admin console.
+ *
+ * Why this is needed: Claude Code applies the cache at startup, then refetches
+ * from Anthropic in the background. When the org has no server-managed config,
+ * that refetch overwrites the cache with {} -- so a hand-placed payload is good
+ * for exactly one session and must be re-applied before each restart.
+ *
+ * Usage:  node apply-local-cache.js [--revert]
+ *
+ * Restart Claude Code IMMEDIATELY after running this. OpenTelemetry settings
+ * are only read at startup, and the background fetch will blank the file.
+ */
+
+const fs = require('fs');
+const path = require('path');
+const http = require('http');
+
+const HOME = process.env.USERPROFILE || process.env.HOME;
+const CACHE = path.join(HOME, '.claude', 'remote-settings.json');
+const SOURCE = path.join(__dirname, 'local-test-settings.json');
+
+if (process.argv.includes('--revert')) {
+  fs.writeFileSync(CACHE, '{}\n');
+  console.log(`reverted ${CACHE} to {}`);
+  process.exit(0);
+}
+
+const source = JSON.parse(fs.readFileSync(SOURCE, 'utf8'));
+
+// Drop the _comment-style documentation keys; they would be stripped by
+// Claude Code's schema validation anyway.
+const payload = Object.fromEntries(Object.entries(source).filter(([k]) => !k.startsWith('_')));
+
+if (!payload.env || !Object.keys(payload.env).length) {
+  console.error(`no env block found in ${SOURCE}`);
+  process.exit(1);
+}
+
+fs.writeFileSync(CACHE, JSON.stringify(payload, null, 2) + '\n');
+console.log(`wrote ${Object.keys(payload.env).length} env vars to ${CACHE}`);
+
+const endpoint = payload.env.OTEL_EXPORTER_OTLP_ENDPOINT || '';
+console.log(`endpoint: ${endpoint}`);
+
+// Check the collector is actually listening -- restarting into a dead endpoint
+// wastes a whole session, since the payload only survives one startup.
+const m = endpoint.match(/^http:\/\/([^:/]+):(\d+)/);
+if (!m) {
+  console.log('\nendpoint is not local http; skipping reachability check');
+  return finish();
+}
+
+// Send the same auth header the client will use, so the probe exercises the
+// collector's bearertokenauth too. 401 = token mismatch, not unreachable.
+const headers = { 'Content-Type': 'application/json' };
+for (const pair of (payload.env.OTEL_EXPORTER_OTLP_HEADERS || '').split(',')) {
+  const i = pair.indexOf('=');
+  if (i > 0) headers[pair.slice(0, i).trim()] = pair.slice(i + 1).trim();
+}
+
+const req = http.request(
+  { method: 'POST', hostname: m[1], port: Number(m[2]), path: '/v1/logs', headers, timeout: 4000 },
+  (res) => {
+    res.resume();
+    console.log(res.statusCode === 401
+      ? 'collector: reachable but rejected the bearer token (HTTP 401) -- OTEL_EXPORTER_OTLP_HEADERS must match the collector OTLP_BEARER_TOKEN'
+      : `collector: reachable (HTTP ${res.statusCode})`);
+    finish();
+  }
+);
+req.on('error', (e) => {
+  console.log(`collector: NOT reachable (${e.code})`);
+  console.log('  start it first:  podman start datex-otel-collector');
+  finish();
+});
+req.on('timeout', () => { req.destroy(); console.log('collector: timeout'); finish(); });
+req.end('{}');
+
+function finish() {
+  console.log('\nRestart Claude Code now -- the background fetch will blank this file.');
+  console.log('Approve the OTEL_EXPORTER_OTLP_ENDPOINT dialog on startup, or Claude Code exits.');
+}

datex_studio_cli-0.4.18/otel/collector-config.yaml

@@ -0,0 +1,145 @@
+# OpenTelemetry Collector configuration for Claude Code telemetry -> Datadog.
+#
+# Claude Code clients send OTLP over http/protobuf to this collector; the
+# collector holds the only copy of the Datadog API key. Developer machines
+# never see a credential.
+
+extensions:
+  # Liveness/readiness endpoint for orchestrator probes (Azure Container Apps)
+  # and local checks: GET http://localhost:13133/health
+  health_check:
+    endpoint: 0.0.0.0:13133
+
+  # Clients must present this token (pushed to them as OTEL_EXPORTER_OTLP_HEADERS
+  # in the same settings payload). Defense in depth on top of network/ingress
+  # restriction -- the receiver is the sole write path into the Datadog org.
+  bearertokenauth:
+    scheme: Bearer
+    token: ${env:OTLP_BEARER_TOKEN}
+
+receivers:
+  # http/protobuf only -- it is all Claude Code speaks. No gRPC listener:
+  # an unused port on this receiver is pure attack surface.
+  otlp:
+    protocols:
+      http:
+        endpoint: 0.0.0.0:4318
+        auth:
+          authenticator: bearertokenauth
+
+processors:
+  # First in every pipeline: refuse new data instead of dying when memory runs
+  # hot. Percentages are relative to the container memory limit -- always run
+  # this image with an explicit limit and GOMEMLIMIT at ~80% of it
+  # (docker-compose.yml shows the pattern for local).
+  memory_limiter:
+    check_interval: 1s
+    limit_percentage: 80
+    spike_limit_percentage: 25
+
+  # Claude Code sends no hostname, which makes Datadog tag every span
+  # issue_type:empty_hostname. Detecting it here fixes grouping.
+  #
+  # CAVEAT: this reports the COLLECTOR's hostname, not the developer's. With a
+  # single shared collector every developer's telemetry carries the same
+  # host.name. Group per developer by user.email or session.id instead. Drop
+  # this processor if host-level grouping matters more than filling the field.
+  resource_detection:
+    detectors: [env, system]
+    system:
+      hostname_sources: [os]
+
+  # Claude Code sends BOTH `prompt` (the prompt text) and `prompt.id` (a uuid).
+  # Datadog flattens dotted keys into nested objects, so `prompt.id` becomes an
+  # object at `prompt` and silently discards the sibling string -- the prompt
+  # text vanishes while `prompt_length` still reports its real size.
+  #
+  # Renaming the string before export sidesteps the collision. Slash-command
+  # prompts were unaffected because command dispatches carry no `prompt.id`,
+  # which is why prompt text only ever showed up for them.
+  transform:
+    error_mode: ignore
+    log_statements:
+      - context: log
+        statements:
+          - set(attributes["prompt_text"], attributes["prompt"]) where IsString(attributes["prompt"])
+          - delete_key(attributes, "prompt") where attributes["prompt_text"] != nil
+    # The traces beta puts prompt/tool content on spans and span events
+    # (OTEL_LOG_TOOL_CONTENT). If those carry the same prompt + prompt.id pair,
+    # the identical flattening collision recurs in Datadog APM. Precautionary
+    # mirror -- verify against a live trace; drop if spans never carry `prompt`.
+    trace_statements:
+      - context: span
+        statements:
+          - set(attributes["prompt_text"], attributes["prompt"]) where IsString(attributes["prompt"])
+          - delete_key(attributes, "prompt") where attributes["prompt_text"] != nil
+      - context: spanevent
+        statements:
+          - set(attributes["prompt_text"], attributes["prompt"]) where IsString(attributes["prompt"])
+          - delete_key(attributes, "prompt") where attributes["prompt_text"] != nil
+
+  # Sized to Datadog's documented example for this exporter. Batch limits count
+  # ITEMS, not bytes -- content-bearing events run up to 60 KB each, and
+  # oversized batches can exceed Datadog's ~5 MB uncompressed logs intake cap.
+  batch:
+    send_batch_size: 10
+    send_batch_max_size: 100
+    timeout: 10s
+
+exporters:
+  datadog:
+    api:
+      key: ${env:DD_API_KEY}
+      site: ${env:DD_SITE}
+    # In-memory queue only -- diskless by choice. Failure behavior:
+    #  - retries never give up on elapsed time (max_elapsed_time: 0), so a
+    #    Datadog outage of any length is survived as long as the queue holds
+    #    (permanent 4xx errors are still dropped, not retried -- a bad API key
+    #    can't jam the queue)
+    #  - the queue absorbs outages/bursts; memory_limiter stops intake before
+    #    queue growth can OOM the container
+    #  - when the queue IS full, new data drops and
+    #    otelcol_exporter_enqueue_failed_* counts it -- alert on that metric
+    #  - a container restart loses whatever is queued; accepted cost of
+    #    staying diskless
+    retry_on_failure:
+      enabled: true
+      initial_interval: 5s
+      max_interval: 60s
+      max_elapsed_time: 0
+    sending_queue:
+      enabled: true
+      num_consumers: 10
+      queue_size: 5000
+
+  # Wired into every pipeline so container logs confirm data is arriving.
+  #
+  # verbosity: basic logs per-batch item COUNTS only. Do not raise this to
+  # detailed outside short local debugging -- detailed writes full payloads to
+  # container stdout, and those payloads contain prompts, responses and the
+  # contents of any file Claude Code read.
+  debug:
+    verbosity: basic
+
+service:
+  extensions: [health_check, bearertokenauth]
+
+  pipelines:
+    logs:
+      receivers: [otlp]
+      processors: [memory_limiter, resource_detection, transform, batch]
+      exporters: [datadog, debug]
+
+    traces:
+      receivers: [otlp]
+      processors: [memory_limiter, resource_detection, transform, batch]
+      exporters: [datadog, debug]
+
+    metrics:
+      receivers: [otlp]
+      processors: [memory_limiter, resource_detection, batch]
+      exporters: [datadog, debug]
+
+  telemetry:
+    logs:
+      level: info

datex_studio_cli-0.4.18/otel/docker-compose.yml

@@ -0,0 +1,19 @@
+# Local verification harness. Azure deployment uses the image directly.
+services:
+  otel-collector:
+    build: .
+    image: datex-claude-otel-collector:local
+    container_name: datex-otel-collector
+    env_file:
+      - .env
+    environment:
+      # ~80% of mem_limit, so Go's GC cooperates with the memory_limiter
+      # processor instead of the kernel OOM-killing the container.
+      GOMEMLIMIT: 400MiB
+    ports:
+      # Loopback only: the receiver is a write path into the org's Datadog
+      # account -- don't expose it to every peer on the office/VPN network.
+      - "127.0.0.1:4318:4318"
+      - "127.0.0.1:13133:13133"
+    mem_limit: 512m
+    restart: unless-stopped

datex_studio_cli-0.4.18/otel/local-test-settings.json

@@ -0,0 +1,26 @@
+{
+  "_comment": "Local verification only. Merge this env block into your own ~/.claude/settings.json while testing the collector on localhost, then remove it once server-managed settings are live. Same keys as remote-settings.json except OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS (local-dev token, matching .env.example) and deployment.environment. Again no Datadog key -- the collector holds it.",
+
+  "env": {
+    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
+    "CLAUDE_CODE_ENHANCED_TELEMETRY_BETA": "1",
+
+    "OTEL_LOGS_EXPORTER": "otlp",
+    "OTEL_TRACES_EXPORTER": "otlp",
+    "OTEL_METRICS_EXPORTER": "otlp",
+    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
+    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://localhost:4318",
+    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer local-dev-token",
+
+    "OTEL_METRIC_EXPORT_INTERVAL": "60000",
+    "OTEL_METRICS_INCLUDE_SESSION_ID": "true",
+
+    "OTEL_SERVICE_NAME": "claude-code",
+    "OTEL_RESOURCE_ATTRIBUTES": "deployment.environment=local,service.version=1.0",
+
+    "OTEL_LOG_USER_PROMPTS": "1",
+    "OTEL_LOG_ASSISTANT_RESPONSES": "1",
+    "OTEL_LOG_TOOL_DETAILS": "1",
+    "OTEL_LOG_TOOL_CONTENT": "1"
+  }
+}

datex_studio_cli-0.4.18/otel/remote-settings.json

@@ -0,0 +1,36 @@
+{
+  "_comment": "Paste the contents of this file (minus the _comment keys) into claude.ai > Admin Settings > Claude Code > Managed settings. Requires Owner or Primary Owner role and a Claude for Teams/Enterprise plan. The only secret here is the shared collector bearer token; the Datadog API key lives only on the collector.",
+
+  "_endpoint_note": "Replace <COLLECTOR-PUBLIC-URL> with the collector's public TLS URL (e.g. https://otel.example.com). That is the TLS front end -- Azure Container Apps ingress listens on 443 -- NOT the collector's internal port 4318, which ingress targets. Must be HTTPS in production: OTLP payloads carry full prompts and responses. Claude Code always shows each developer a one-time approval dialog for a non-empty OTEL_EXPORTER_OTLP_ENDPOINT; if they decline, Claude Code exits.",
+
+  "_auth_note": "Replace <OTLP-BEARER-TOKEN> with the token configured on the collector (its OTLP_BEARER_TOKEN secret). It is a shared, developer-visible secret: defense in depth on top of ingress restriction, not a substitute for it.",
+
+  "env": {
+    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
+    "CLAUDE_CODE_ENHANCED_TELEMETRY_BETA": "1",
+
+    "OTEL_LOGS_EXPORTER": "otlp",
+    "OTEL_TRACES_EXPORTER": "otlp",
+    "OTEL_METRICS_EXPORTER": "otlp",
+    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
+    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://<COLLECTOR-PUBLIC-URL>",
+    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer <OTLP-BEARER-TOKEN>",
+
+    "OTEL_METRIC_EXPORT_INTERVAL": "60000",
+    "OTEL_METRICS_INCLUDE_SESSION_ID": "true",
+
+    "OTEL_SERVICE_NAME": "claude-code",
+    "OTEL_RESOURCE_ATTRIBUTES": "deployment.environment=dev,service.version=1.0",
+
+    "OTEL_LOG_USER_PROMPTS": "1",
+    "OTEL_LOG_ASSISTANT_RESPONSES": "1",
+    "OTEL_LOG_TOOL_DETAILS": "1",
+    "OTEL_LOG_TOOL_CONTENT": "1"
+  },
+
+  "_metrics_note": "Metrics use Claude Code's default delta temporality (what Datadog expects) and the default-off app.version attribute. session.id is kept on metrics for session-level drill-down -- an accepted Datadog custom-metric cardinality cost, since every session mints new timeseries; set it to false if the custom-metrics bill grows. Per-developer analysis uses user.email either way.",
+
+  "_enforcement_note": "forceRemoteSettingsRefresh makes the CLI exit rather than run unenforced when the settings fetch fails. requiredMinimumVersion stops developers dropping to a build that ignores server-managed settings (NOTE: this key is not in Anthropic's public docs -- confirm it is honored, or it may be silently stripped). Neither makes this a security boundary -- see README.",
+  "forceRemoteSettingsRefresh": true,
+  "requiredMinimumVersion": "2.1.220"
+}

{datex_studio_cli-0.4.16 → datex_studio_cli-0.4.18}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "datex-studio-cli"
-version = "0.4.16"
+version = "0.4.18"
 description = "CLI for Datex Studio low-code platform, designed for LLM-based AI agents"
 readme = "README.md"
 license = "MIT"

{datex_studio_cli-0.4.16 → datex_studio_cli-0.4.18}/src/dxs/__init__.py

@@ -1,4 +1,4 @@
 """Datex Studio CLI - Command-line interface for Datex Studio platform."""
 
-__version__ = "0.4.16"
+__version__ = "0.4.18"
 __app_name__ = "dxs"