github / github/copilot-cli

Add native timestamp option for CLI output

Offen
#1,956 0 Kommentare 12 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
area:configuration area:terminal-rendering
Vorherrschende Sprache
Shell
Sterne
11.2k
Forks
1.9k
Ø Merge
14 Std. 16 Min.
Gemergte PRs (30 T.)
6

Beschreibung

### Describe the feature or problem you'd like to solve

During long-running Copilot CLI sessions (infrastructure deployments, multi-step debugging, CI/CD troubleshooting), there's no built-in way to see when each response was produced. This makes it difficult to: - Correlate Copilot actions with external events (pipeline runs, deployments, log entries) - Gauge how long operations took - Review session history with temporal context The current workaround is adding "Timestamp every response" to custom instructions. This is unreliable — it consumes context tokens, can be lost during context compaction, and depends on the model inferring the local timezone (e.g. via `Get-TimeZone`) rather than knowing it natively.

### Proposed solution

A configuration option that prepends a local-timezone timestamp to each Copilot response, handled by the CLI runtime rather than the model.

For example, a config file setting:

```yaml
# ~/.copilot/config.yml
output:
timestamps: true
timestamp_format: "HH:mm z" # optional, sensible default

Or a CLI flag: copilot --timestamps

Benefits:

- Reliable — not dependent on model compliance or context window state
- Zero token cost — handled by the CLI runtime, not the model
- Accurate — the CLI knows the local timezone; the model has to guess
- Consistent — same format every time, not subject to model variation

### Example prompts or workflows

1. Infrastructure deployment session — deploying Azure resources over 30+ minutes, needing to cross-reference Copilot actions with Azure Activity Log timestamps to diagnose deployment failures.
2. CI/CD pipeline debugging — triggering builds, waiting for results, checking logs. Timestamps let you match "I queued the build at 15:21" with pipeline logs showing the failure at 15:23.
3. Multi-step troubleshooting — diagnosing a production issue across Container Apps logs, Front Door health probes, and DNS propagation. Each step produces output minutes apart; without timestamps you lose the timeline.
4. Session review — scrolling back through a long session to find "that thing Copilot did around 2pm" is impossible without timestamps in the output.
5. Collaborative handoff — sharing a session transcript with a colleague. Timestamps make it immediately clear what happened when.

### Additional context

I currently use a custom instruction workaround that works well when the model follows it, but it's fragile across context compactions and adds unnecessary token overhead. A native runtime-level feature would be a small change with outsized quality-of-life impact for power users running extended sessions.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.