Skip to main content

Dashboard Logs

CCS includes a dedicated System -> Logs workspace for operational visibility. It combines CCS-owned structured runtime logs with a compatibility view of legacy CLIProxy error files.

Access

ccs config
# Open System -> Logs
# Or navigate directly to /logs inside the current dashboard session

What You See

Telemetry Stream

The primary tab reads CCS-owned structured logs from the native logging lane. Use it to:
  • filter by source and level
  • inspect recent entries without opening raw files
  • open a detail panel for event context
  • adjust retention and redaction settings from the dashboard
  • refresh sources and entries without leaving the page

Legacy Errors

The secondary tab keeps old CLIProxy-style error files visible so you can still inspect provider failures written under the CLIProxy runtime logs directory. This is a compatibility surface, not the primary logging model.

Storage Model

CCS-Owned Structured Logs

Native CCS logs live under:
~/.ccs/logs/current.jsonl
~/.ccs/logs/archive/
These logs are controlled by the top-level logging config block and support:
  • minimum log level
  • log rotation by size
  • archive retention by day count
  • context redaction
  • a bounded in-memory buffer for dashboard reads

CLIProxy Runtime Logs

CLIProxy runtime files still live under:
~/.ccs/cliproxy/logs/
Those files are controlled separately through cliproxy.logging.

Configuration

logging:
  enabled: true
  level: info
  rotate_mb: 10
  retain_days: 7
  redact: true
  live_buffer_size: 250
This is separate from:
cliproxy:
  logging:
    enabled: false
    request_log: false
Use top-level logging for CCS-owned runtime events. Use cliproxy.logging only when you need extra CLIProxy runtime files for troubleshooting.

Operational Notes

  • Dashboard /api/logs reads are intentionally skipped by request logging so the log viewer does not recursively log itself.
  • Remote users can inspect logs only within the dashboard access rules currently enforced by dashboard auth and localhost-only fallbacks.
  • Redaction is enabled by default so persisted context does not leak obvious secrets into the log stream.

Troubleshooting

The Logs page looks empty

  • Check whether top-level logging.enabled is still true
  • Trigger a fresh CCS action, then refresh the page
  • If you only enabled cliproxy.logging, look in the Legacy Errors tab

I only need verbose CLIProxy request traces

Enable cliproxy.logging.request_log instead of raising the global CCS logging level unless you specifically want broader CCS runtime telemetry.