Summary

Add a new CLI flag --log-for human|machine to make Dev Proxy output consumable by coding agents and LLMs.

Problem

The current console output is optimized for human readability but creates problems when consumed by LLMs/coding agents:

Example of current output

 req   ╭ GET https://api.example.com/users
 oops  │ 429 TooManyRequests
 warn  │ Exceeded resource limit when calling https://api.example.com/users
       ╰ 

What an agent needs

{"type":"request","method":"GET","url":"https://api.example.com/users","requestId":"1","timestamp":"2026-01-19T10:30:00.000Z"}
{"type":"chaos","plugin":"RateLimitingPlugin","status":429,"message":"TooManyRequests","requestId":"1","timestamp":"2026-01-19T10:30:00.050Z"}
{"type":"warning","plugin":"RateLimitingPlugin","message":"Exceeded resource limit","url":"https://api.example.com/users","requestId":"1","timestamp":"2026-01-19T10:30:00.051Z"}

Proposed solution

Add a new flag:

devproxy --log-for human   # Current behavior (default)
devproxy --log-for machine # Structured JSON Lines output

Why --log-for instead of --output json or --format json?

We evaluated common CLI conventions:

However, for LLM consumption, audience-centric naming is more intuitive than format-centric:

An LLM reading --help naturally self-identifies with --log-for machine.

Machine output requirements

When --log-for machine is set:

1. JSON Lines format — one JSON object per line (streamable)
2. No ANSI codes — strip all color/formatting escape sequences
3. No Unicode decorations — no box-drawing characters
4. Include correlation IDs — requestId in every log entry
5. Include timestamps — ISO 8601 format
6. Full context — URL, method, plugin name in each entry
7. Semantic message types — request, response, warning, error, mock, chaos (not oops, skip)

Configuration

Also support in devproxyrc.json:

{
  "logFor": "machine"
}

Related

• Reporters (JsonReporter, PlainTextReporter) handle file output after recording
• This flag handles real-time console/stdout output