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

What would GitHub Actions look like if you designed it today?
GHA was designed in ~2018. What would it look like if you designed it today, with all we know now?

Truly continuous integration: ensuring pull requests from agents have passing builds
RWX CLI v3.0.0 introduces new tools for developers and coding agents to iterate on changes until CI passes - without a single commit or push.

