Runtimes
What works where, and where the rough edges are.
The telemetry footer is a prompt — it relies on the runtime executing a Skill capability in your plugin to actually post the event. Reliability varies; here's what we've seen.
| Runtime | invocation.end | script.invoked | modification check | feedback ask |
|---|---|---|---|---|
| Claude Code | ✓ reliable | ✓ deterministic | ✓ filesystem available | ✓ |
| Codex CLI | ✓ usually | ✓ deterministic | ⚠ no stable install id | ⚠ inconsistent |
| Codex IDE / app | ⚠ calibrating | ✓ when scripts run | ⚠ calibrating | ⚠ |
| Cowork | ⚠ calibrating | ✓ deterministic | ⚠ sandboxed | ⚠ |
ChatGPT and Codex share a public plugin directory, but component execution depends on the surface. ChatGPT Work can run plugin capabilities where its execution environment supports them; telemetry requires an explicit integration that emits Telvine events. The table above does not establish measured ChatGPT telemetry reliability. Test web and desktop environments separately before rollout.
If your runtime sandboxes filesystem access, the installation_id falls back to
a hash of the project root. This means moving the project changes the id; that's
intentional and documented.
The script wrapper (under scripts/.telvine-wrappers/) does not depend on the
runtime and is the canonical signal for "the plugin capability actually executed something".
Plugin component inventory is deterministic at publish time. Runtime events for hooks, MCP config wrappers, apps, connectors, and agents are accepted only when their integration or wrapper can emit them; an installed component is not evidence that it executed.