Summary

Add a dedicated access log that records the commands Vigilante runs, so operators can see how the daemon and issue sessions are interacting with external tools, especially GitHub via gh. The immediate goal is visibility: understand the real command/query pattern first, then use that data to optimize GitHub usage later.

Problem

• Vigilante already has daemon logs, per-issue session logs, and privacy-aware telemetry, but it does not have a simple access-log view of the commands it is actually executing.
• It is currently hard to see, in one place, how often Vigilante is calling gh, which command shapes it is using, and whether daemon scans or session workflows are generating redundant GitHub traffic.
• That makes it difficult to reason about GitHub query volume, diagnose inefficiencies, or prioritize optimization work based on actual behavior.

Context

• Repository: aliengiraffe/vigilante
• Existing logging/observability surfaces already include:
  • daemon log output under ~/.vigilante/logs/
  • per-issue session logs
  • anonymous telemetry with bounded/sanitized command-shape data
• Current docs explicitly mention GitHub-heavy operations such as gh api /rate_limit, issue polling, PR inspection, issue comments, and PR maintenance.
• The requested new log is different from telemetry: it should be a local operator-facing log that makes command execution easy to inspect directly.
• The user intent is to monitor all commands Vigilante is running, with particular emphasis on how it queries GitHub, across both:
  • long-running daemon/service activity
  • normal issue/session execution activity

Desired Outcome

• Vigilante writes a dedicated access log that records every subprocess/tool command it runs in a consistent, inspectable format.
• The access log covers both daemon-driven commands and normal session-execution commands.
• The log makes GitHub access patterns easy to understand, especially gh and gh api usage.
• The access log is useful for later optimization analysis without requiring OTLP/PostHog telemetry access.
• Non-goal: implementing the GitHub-query optimization itself in this change.

Implementation Notes

• Add a separate access-log stream/file rather than burying this data inside the existing daemon log prose.
• Record enough data per command to make the log operationally useful. Likely fields include:
  • timestamp
  • execution context (daemon, session, maintenance, or similar)
  • repo/issue/session identifiers when available
  • command/tool name and argv or a clearly defined command-shape representation
  • start/end or duration
  • exit status
• Be explicit about privacy/redaction rules. The user asked to log all commands, but implementation should still avoid leaking secrets or tokens into the access log.
• Prefer a format that is easy to grep and later aggregate, such as line-delimited structured JSON or another clearly documented structured format.
• Ensure the access log includes daemon service calls made during scans, polling, maintenance, and control handling, not just per-issue coding-agent runs.
• Ensure normal issue/session execution calls are also captured, including GitHub operations, git operations, provider invocations, and other external tool calls executed by Vigilante.
• Review whether the existing logs command should expose the new access log explicitly so operators can inspect it without browsing the filesystem manually.
• Update README/docs to explain the purpose and location of the access log.

Acceptance Criteria

• Vigilante writes a dedicated access log for subprocess/tool commands it executes.
• The access log captures both daemon/service-driven commands and normal session-execution commands.
• GitHub command activity, especially gh and gh api usage, is clearly visible in the access log.
• Each access-log entry includes enough context to distinguish what was run, when it ran, where it came from, and whether it succeeded.
• Sensitive values such as tokens or equivalent secrets are not written to the access log.
• The location/format of the access log is documented for operators.
• If Vigilante has a local logs-inspection command, it is updated as needed so the access log is discoverable there too.
• Automated tests cover access-log writing for both daemon-context and session-context command execution.

Testing Expectations

• Add or update tests for the command-execution path so access-log entries are emitted for representative external commands.
• Add coverage for both daemon-style flows and normal issue/session execution flows.
• Add redaction tests to confirm sensitive values are not persisted in the access log.
• Verify that representative GitHub operations such as gh api, gh issue, and gh pr appear in the new log as expected.
• If the logs CLI surface changes, add or update tests covering access-log discovery/read behavior.

Operational / UX Considerations

• The access log should be easy to correlate with the existing daemon log and per-issue session logs without replacing them.
• The format should optimize for later analysis of GitHub call volume and repetition, not just human prose readability.
• Keep the first version focused on visibility and trustworthy recording; deeper summarization or optimization can happen in follow-up work.