trace: expand same-call attribution beyond foreground Claude Bash

Aperta
  • Qualcosa non va?
#3,701 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
bash, git, go
Ambito
cli, developer-experience, tooling

Direzione di ricerca

Start with the implementation and tests for PR #3631, which handles foreground native Claude Code Bash calls using the hook input update mechanism, and review the related context in #3625. Map the existing capability reporting and integration tests for each provider/runtime, then investigate background process lifecycle, hook composition, and permission matching. Done means supported combinations have tested exact call correlation and unsupported combinations clearly report their limitation.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

chainloop component/CLI trace-provider

Context

Follow-up to #3625 and PR #3631. The PR is intentionally scoped to a foreground native Claude Code Bash call, following maintainer review.

It currently uses Claude Code's hook input update mechanism to export an opaque call token into the command before Git hooks run.

Scope

Investigate and implement broader runtime support for same-call commit attribution:

  • background Bash calls whose process can outlive PostToolUse;
  • coexistence with another hook that also rewrites updatedInput;
  • narrow Bash permission matchers that can behave differently after command rewriting;
  • Cursor, OpenCode, and other providers that do not expose the same pre-execution command-rewrite contract;
  • explicit capability reporting when exact call correlation is unavailable.

Expected behavior

Every supported provider/runtime has a documented, tested way to correlate a Git hook with the exact command call that made the staged change. Unsupported combinations fail visibly or remain explicitly documented as unsupported instead of silently losing attribution.

Acceptance criteria

  • Background-call lifecycle and snapshot retention are defined and tested.
  • Multiple input-rewriting hooks have deterministic composition or a documented incompatibility.
  • Narrow permission configurations retain their intended behavior.
  • Each provider's capability matrix entry matches observable support.
  • Unsupported runtimes surface a clear limitation or warning.
  • Integration tests cover every provider/runtime combination declared supported.
Lingua principale
Go
Stelle
582
Fork
61
Merge medio
12h 47m
PR unite (30g)
137

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di chainloop-dev/chainloop

Tutte le issue di chainloop-dev/chainloop

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.