Zed Codex heartbeats lose editor and project context

[qqmikey]

Summary

When Codex is used inside Zed with the zed-wakatime extension enabled, some emitted heartbeats arrive as low-context app events such as type=app, entity="Codex", with no project, branch, language, or explicit editor, which makes Waka-compatible backends classify them as unknown activity instead of attributing them to the active file or project.

Impact

This makes downstream analytics noisy and misleading for users who rely on Waka-compatible servers outside the hosted WakaTime backend. Instead of seeing file/project-level activity from Zed, they receive repeated generic Codex app heartbeats that cannot be grouped correctly by project, language, or editor.

Current Behavior

1. Install Zed with the zed-wakatime extension enabled.
2. Use Codex from inside Zed.
3. Inspect emitted heartbeats on a Waka-compatible backend.
4. Some heartbeats arrive with payloads similar to:

{
  "time": 1775101100,
  "type": "app",
  "branch": "",
  "entity": "Codex",
  "project": "",
  "category": "ai coding",
  "is_write": false,
  "user_agent": "wakatime/v2.0.13 (darwin-24.6.0-arm64) go1.25.5 Zed/0.229.0+dev.27f70d2f56eb01f18b2a10131663c9fd4de4b37d Zed-wakatime/0.1.10 Codex/0.117.0"
}

Observed result:

• project is empty
• branch is empty
• language is absent
• editor is absent from the heartbeat body
• entity is just Codex

Expected Behavior

When Codex activity is tracked through Zed, emitted heartbeats should preserve enough source context for Waka-compatible backends to attribute the activity meaningfully. At minimum, the emitted data should make it possible to identify the editor and, when applicable, the active file/project context rather than collapsing to a generic Codex app heartbeat.

Root Cause

Root cause not fully confirmed from the extension side yet, but the current emitted heartbeat shape appears to rely on downstream WakaTime-specific interpretation of user_agent / plugin metadata rather than sending explicit editor or file/project context in the heartbeat body.

Proposed Resolution

1. Review how zed-wakatime emits heartbeats for Codex-driven activity and identify why they fall back to generic type=app / entity="Codex" payloads.
2. Ensure the extension includes sufficient explicit context in the emitted heartbeat body, especially editor, and preserve file/project/language context whenever it exists in Zed.
3. If generic app-level Codex heartbeats are intentional, document that behavior and clarify how non-WakaTime backends are expected to interpret them.

Test Plan

• Unit: add coverage for Codex-related heartbeat shaping so editor/context fields are asserted explicitly.
• Integration: verify heartbeats captured from Zed while using Codex against a Waka-compatible backend that stores raw payloads.
• Manual smoke:
  • Enable zed-wakatime, use Codex in Zed, and inspect the raw emitted heartbeat.
  • Confirm that project/editor/language/file context is present when available.
• Commands:
  • cargo test
  • cargo fmt --check

Acceptance Criteria

• Codex-related heartbeats emitted by zed-wakatime no longer collapse to generic entity="Codex" payloads when richer editor/file/project context is available.
• Emitted heartbeats include enough explicit context for a Waka-compatible backend to classify the activity without relying solely on user_agent parsing.
• Expected behavior for intentional app-level Codex heartbeats is documented if full file/project attribution is not possible.
• Regression coverage is added for the Codex heartbeat shape.

Definition of Done

• Implementation merged
• Required checks are green
• Docs updated if behavior/contract changed