One of the strengths of RWX's CI/CD platform is its semantic output of test results, which makes it easy to see failure details in the UI. These semantic outputs are also the primary way failed tests are consumed by AI assistants using our MCP server.
However, it's often useful to pull logs for a task or a group of tasks in order to dig deeper into stack traces and print/trace debugging output. Our UI, of course, supports downloading task logs, but we've also recently shipped support for pulling logs with the RWX CLI, to help enable local and/or automated workflows.
Starting in version 2.3.0 of the CLI, logs can be pulled with rwx logs <taskId>, using the task ID in the URL of the RWX UI.
This command supports several flags, documented here.
#Kicking off automated workflows
The file paths of the log files can be piped into tools like jq, by using the --json flag as shown in the simple example below, which would find the log files with the string "ERROR" in them:
$ rwx logs <taskId> --auto-extract --json |jq -r '.outputFiles[]' | xargs grep -l "ERROR"
#Working with AI agents and assistants
Log files can be particularly helpful when having an AI agent or assistant debug complex logs. When using rwx logs, you can specify the download location to ensure your AI assistant has access to them, and if you're using our MCP server to fetch failed task information, that will also include instructions for your agent on how to download logs itself as needed.
Naturally, best practices on how to leverage LLMs in our workflows continue to evolve, so if you have other use cases around processing logs, we'd love to hear from you.
#Our evolving CLI vs MCP philosophy
When putting together our logs tooling, our original goal was to serve logs to MCP clients, but we knew we didn't want to just dump thousands of log lines into the prompt we returned from our MCP server. Additionally, an emerging best practice with MCP servers is to use a smaller subset of tools at a time to avoid context bloat (as described in this blog post and bemoaned by Reddit users here).
What this means is that, while some users will have their AI agents interact with RWX's MCP server, it shouldn't be the only way to get the data you're looking for. This led us to first extending our CLI to support logs functionality, and then allowing our MCP server to inform AI agents about that tooling.
As our AI-related tooling continues to evolve, we'll be using this new rule of thumb to ensure that better tooling for AI also results in better tooling for humans.
Related posts

New Base Config to Run Directly from Container Images
We just shipped a change to how base images work on RWX. Base images are now configured directly from container images.

Zero configuration CI/CD Observability on RWX using OpenTelemetry
CI/CD performance shouldn’t degrade quietly. Now it doesn’t have to.

