Summary
When calling the logs tool with --engine copilot filter, the filter correctly returns only copilot-engine workflow runs — but in every returned run object, both the engine and engine_id fields are None. The engine information is actually stored in a separate agent field ("agent": "copilot"). This creates a naming mismatch that can confuse downstream tooling and agents.
Steps to Reproduce
- Call
logs with engine filter: --engine copilot --count 3
- Parse the returned run objects
- Check the
engine and engine_id fields
Observed Behavior
All returned run objects have:
{
"agent": "copilot",
"engine": null,
"engine_id": null,
...
}
The --engine copilot filter does return the correct workflows (filtered correctly), but the engine/engine_id output fields are unpopulated.
Expected Behavior
The engine and engine_id fields in the output should be populated to match the value used for filtering. Ideally one of:
engine/engine_id are populated from the agent field value, or
- The output documents that
agent is the correct field to read (and engine/engine_id are deprecated/removed)
Evidence
Run data from logs --engine copilot --count 3 (all 3 runs showed this):
workflow: Daily CLI Tools Exploratory Tester → agent: 'copilot' engine: None engine_id: None
workflow: Test Quality Sentinel → agent: 'copilot' engine: None engine_id: None
workflow: Copilot PR Prompt Pattern Analysis → agent: 'copilot' engine: None engine_id: None
Note: Non-filtered logs calls show the same pattern — engine is always None, agent is populated.
Impact
- Severity: Medium
- Frequency: Always — reproducible on every
logs call
- Affected: Any tooling or agent that reads
engine/engine_id from log results (instead of agent)
- Workaround: Read the
agent field instead of engine/engine_id
Additional Context
- Discovered during daily exploratory testing of CLI tools (run §24650053759)
- Date: 2026-04-20
- All 196 workflows compiled successfully; no compilation issues found
audit and logs tools otherwise functioning correctly
Generated by Daily CLI Tools Exploratory Tester · ● 1.7M · ◷
Summary
When calling the
logstool with--engine copilotfilter, the filter correctly returns only copilot-engine workflow runs — but in every returned run object, both theengineandengine_idfields areNone. The engine information is actually stored in a separateagentfield ("agent": "copilot"). This creates a naming mismatch that can confuse downstream tooling and agents.Steps to Reproduce
logswith engine filter:--engine copilot --count 3engineandengine_idfieldsObserved Behavior
All returned run objects have:
{ "agent": "copilot", "engine": null, "engine_id": null, ... }The
--engine copilotfilter does return the correct workflows (filtered correctly), but theengine/engine_idoutput fields are unpopulated.Expected Behavior
The
engineandengine_idfields in the output should be populated to match the value used for filtering. Ideally one of:engine/engine_idare populated from theagentfield value, oragentis the correct field to read (andengine/engine_idare deprecated/removed)Evidence
Run data from
logs --engine copilot --count 3(all 3 runs showed this):Note: Non-filtered
logscalls show the same pattern —engineis alwaysNone,agentis populated.Impact
logscallengine/engine_idfrom log results (instead ofagent)agentfield instead ofengine/engine_idAdditional Context
auditandlogstools otherwise functioning correctly