Size-based rotation for warp.log within a session (currently startup-only)

[david-engelmann]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

warp_logging::rotate_log_files() rotates warp.log and its telemetry siblings once at app startup: the previous session's log becomes .old.0, older ones shift up to .old.N, and the oldest gets discarded. That model works well for users who restart Warp frequently — each session gets its own log file.

For long-running sessions (developers who keep Warp open for days or weeks), the active warp.log grows unboundedly during a single session, with no checkpoints in between. The startup rotation never fires until the next restart.

Proposal: add an in-session size-based rotation mode to warp_logging, complementing the existing startup rotation. When the active warp.log exceeds a configured size threshold mid-session, it's rotated to an in-session sibling (e.g. warp.log.in_session.N) and a fresh active file is opened. The startup .old.N semantics that log-bundle uploads and other UX depend on stay untouched.

Is your feature request related to a problem? Please describe.

Two related reports for other log files exist:

• MCP server logs (stderr/stdout) are not rotated - can fill disk space #7723 / fix(mcp): size-rotate MCP server log files to cap disk usage (#7723) #10874 — MCP server logs not rotated (simple_logger)
• Rotate LSP server log files (parallel to MCP fix in #10874 / #7723) #10877 — LSP server logs not rotated (simple_logger)

Both of those operate on a different rotation engine than warp.log, but the underlying user complaint is the same: Warp's diagnostic data grows without bound during long sessions. Capping warp.log at e.g. 50 MiB × 5 rotated copies would bound it at ~300 MiB even across multi-day sessions, while preserving the per-session file boundary at startup that today's UX (e.g. log-bundle uploads) relies on.

Additional context

This complements (does not replace) the MCP/LSP rotation work. Different file, different rotation engine, but the same principle: cap on-disk footprint during long sessions while preserving the current per-session semantics.

Sketch of the implementation surface:

• Extend LogConfig with optional max_file_size_bytes (or equivalent threshold)
• Plumb that to the log writer (e.g. tracing-appender's rolling appender, or a manual periodic size check)
• Rotation pattern: e.g. warp.log.in_session.N to distinguish from the existing startup .old.N files

Operating system (OS)

macOS

How important is this feature to you?

3

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

Ignore

[oz-for-oss]

@david-engelmann

Here's what I found while triaging this issue:

Code inspection confirms warp.log rotation is currently startup-only, so this is a valid feature gap for long-running sessions. #7723, #10874, and #10877 are related log-footprint work, but they target MCP/LSP logs rather than the main Warp application log.

Maintainer details

I concluded that request for in-session size-based rotation of the active Warp application log so long-running sessions do not let warp.log grow without bound..

Triage summary

This is a distinct enhancement request for size-based rotation of the active Warp application log during a long-running session. The current logging implementation preserves a per-session boundary by rotating the previous execution at startup, but it does not cap the current session's warp.log while Warp remains open.

Evidence

• LogConfig only carries CLI/destination configuration and has no max-size or retention settings for the active file.
• Logging initialization opens a single active log file and passes it to env_logger::Target::Pipe; there is no size-aware writer wrapper or periodic size check.
• rotate_log_files() is spawned once from app startup and delegates to .old.N rotation for the prior execution's temporary log, plus telemetry when enabled.
• current_and_rotated_log_paths() currently includes the active log and .old.N files for log bundle creation, so an in-session naming scheme would need an explicit decision about whether and how those files are included in uploaded bundles.

Duplicate check

I fetched all open issues and checked recently closed issues allowed by the dedupe workflow. #7723, #10874, and #10877 are related log-footprint work for MCP/LSP logs, but they use different log files/rotation code paths and do not duplicate this warp.log request. No duplicate issue is recommended.

Suggested next step

Route as an enhancement in the logging/performance area. Implementation should preserve the existing startup .old.N semantics while adding a separate in-session retention policy and clarifying log-bundle inclusion for any new in-session files.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[oz-for-oss]

This issue has been labeled ready-to-implement and is open for contributions involving code changes. If you'd like to tackle it, feel free to open a pull request against this issue. You can also comment @oz-agent on this issue to have the bot draft an implementation PR automatically.