feat(docker): add bounded tail reads for log files inside containers #5703

What problem will this feature address?

Applications can write logs to files inside containers without forwarding them to stdout/stderr. For example, Laravel commonly writes to /var/www/html/storage/logs/laravel.log.

The existing docker.readContainerFile endpoint returns only the beginning of a file, capped at 512 KiB, with a truncated flag. It provides no way to request the end of the file. As a result, API and MCP clients may receive old errors while recent entries remain inaccessible through this endpoint.

We encountered this while investigating a Laravel application: container logs showed HTTP access output, while reading laravel.log returned a truncated prefix containing historical exceptions.

This behavior is visible in readContainerFile on canary at e0c8d80: the command uses cat … | head -c ….

Reproduction:

1. Create a text log larger than 512 KiB inside a running container.
2. Append a unique marker such as LATEST_ERROR_MARKER.
3. Call docker.readContainerFile for that path.
4. Observe truncated: true; the latest marker is absent.
5. The endpoint has no tail or offset parameter to retrieve it.

Describe the solution you'd like

Add a read-only docker.readContainerFileTail endpoint, keeping existing file-editor behavior unchanged.

Suggested input:

{
  "containerId": "<container-id>",
  "path": "/var/www/html/storage/logs/laravel.log",
  "lines": 200,
  "maxBytes": 65536
}

Support the existing optional serverId for remote servers. Defaults and upper limits are open to maintainer feedback.

Expected behavior:

• Return the most recent requested lines in their original chronological order.
• Enforce a server-side byte limit, including for extremely long lines.
• When the byte limit is reached, retain the newest content and indicate truncation.
• Return UTF-8 text with explicit truncation metadata.
• Bound memory usage and execution time.
• Preserve authorization and organization/server access checks.
• Validate paths and numeric limits; do not accept arbitrary shell commands.
• Report missing files, unavailable containers, and unsupported container utilities clearly.

Initial scope: a single snapshot read. Live following, search, pagination, and dashboard changes can be separate contributions.

Suggested tests include large files with a marker at EOF, empty files, missing trailing newlines, Unicode boundaries, oversized lines, unusual filenames, failed reads, authorization, and local/remote execution.

Describe alternatives you've considered

• Forward application logs to stderr: useful where configurable, but requires changing each application's logging setup.
• Use SSH or the container terminal: works interactively, but does not provide a bounded, structured API for clients.
• Download the complete file: unnecessary transfer for inspecting recent errors.
• Increase the existing preview limit: still returns the beginning and does not solve the underlying limitation.

Additional context

Related work reviewed:

• feat: unified Docker dashboard with volumes section and file explorer #5027: Docker dashboard and file explorer.
• feat/container filesystem all service types #5194: container filesystem support across service types.
• fix(requests): return the newest access log entries without reading the whole file #4991: reverse reading of Traefik access logs.
• fix(logs): return empty result when readLogs search has no matches #5667: search behavior for container stdout/stderr logs.

These address adjacent functionality. I did not find an equivalent container-file tail endpoint in the PR searches.

The proposed endpoint would also benefit the official MCP once included in its generated tool definitions.

Will you send a PR to implement it?

Yes, after alignment on the API and scope.