fix(desktop): expose task-agent status to chat#8104
Conversation
Git-on-my-level
force-pushed
the
fix/task-agent-status-awareness
branch
from
138f237 to
6d88030
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 138f237bde
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| }, | ||
| { | ||
| name: "get_task_agent_status", |
There was a problem hiding this comment.
This advertises get_task_agent_status from the stdio MCP server, but the tools/call dispatcher below only forwards the existing local/onboarding/backend tool names and otherwise returns Unknown tool (checked the handler around lines 691-856). In ACP/stdio sessions, any model that follows the new prompt guidance and calls this listed tool will get a JSON-RPC -32601 error instead of the Swift registry result, so the subagent-timeout diagnosis still fails for that bridge mode. Add this tool name to a requestSwiftTool path just like get_daily_recap/search_tasks.
Useful? React with 👍 / 👎.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
4 issues found and verified against the latest diff
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Git-on-my-level
left a comment
Git-on-my-level
left a comment
There was a problem hiding this comment.
Addressed the review feedback in 20a005fd7.
Summary:
- Fixed the stdio MCP dispatcher so
get_task_agent_statusis not just advertised, but actually forwarded to Swift viarequestSwiftTool(...). - Bounded task-agent status output:
snapshotJSON()now returns the 20 most recent task-agent entries, and the registry prunes retained history to 100 entries. - Added explicit
stoppedstatus for user-stopped task-agent runs. - Moved terminal status ownership to
TaskChatState;TaskChatCoordinatorno longer infers completion fromerrorMessage == nil, which avoided incorrectly marking stopped runs as completed.
Verification:
git diff --checkswiftc -parseon the modified Swift filesnpm run buildindesktop/macos/agentnpm testindesktop/macos/agent— 74 tests passed
Thanks to cubic and Codex for catching the stdio forwarding gap; cubic also identified the unbounded snapshot and stopped-run status issues.
There was a problem hiding this comment.
1 issue found across 4 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskAgentStatusRegistry.swift">
<violation number="1" location="desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskAgentStatusRegistry.swift:132">
P2: Retention cap is only enforced on update paths, not on task registration. This leaves `entries` effectively unbounded for tasks that are registered but never updated.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| entry.lastError = lastError | ||
| entry.updatedAt = Date() | ||
| entries[taskId] = entry | ||
| pruneIfNeeded() |
There was a problem hiding this comment.
P2: Retention cap is only enforced on update paths, not on task registration. This leaves entries effectively unbounded for tasks that are registered but never updated.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskAgentStatusRegistry.swift, line 132:
<comment>Retention cap is only enforced on update paths, not on task registration. This leaves `entries` effectively unbounded for tasks that are registered but never updated.</comment>
<file context>
@@ -121,5 +129,17 @@ final class TaskAgentStatusRegistry {
entry.lastError = lastError
entry.updatedAt = Date()
entries[taskId] = entry
+ pruneIfNeeded()
+ }
+
</file context>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 20a005fd7b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| activeTaskId = task.id | ||
| markAsRead(task.id) | ||
| TaskAgentStatusRegistry.shared.registerTask(taskId: task.id, title: task.description) |
There was a problem hiding this comment.
This registration only runs when the task chat panel is opened, but background investigations from the scheduler or Tasks page create a TaskChatState and call sendMessage without going through openChat. In that path the new markRunning/markFailed calls create the registry entry with title == nil, so get_task_agent_status reports only an opaque taskId for the background agents/timeouts this tool is meant to diagnose. Register the task in investigateInBackground as well, or pass the task title into the state before sending.
Useful? React with 👍 / 👎.
Git-on-my-level
left a comment
Git-on-my-level
left a comment
There was a problem hiding this comment.
Follow-up for cubic's second-pass comment in 4ada41a4c:
- The retention cap is now enforced on every registry write path:
registerTask(...)updateStatus(...)- terminal updates via the existing shared
update(...)helper
- This means even tasks that are registered and never run/update cannot grow the in-memory registry past the retained-entry cap.
Verification:
git diff --checkswiftc -parseon the modified Swift files
Git-on-my-level
left a comment
Git-on-my-level
left a comment
There was a problem hiding this comment.
Addressed Codex's follow-up comment in a3e65573e:
investigateInBackground(for:)now registers the task withTaskAgentStatusRegistrybefore creating/reusing theTaskChatState.- Background task-agent runs now have the task description/title available in
get_task_agent_status, not just an opaque task id.
Verification:
git diff --checkswiftc -parseon the modified Swift files
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a3e65573e2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| isSending = true | ||
| errorMessage = nil | ||
| TaskAgentStatusRegistry.shared.markRunning(taskId: taskId) |
There was a problem hiding this comment.
When a task-chat bridge fails before streaming starts, such as a missing bridge process or an AgentBridge.start() initialization timeout, ensureBridgeStarted() sets errorMessage and returns at the guard above before this first registry update runs. The coordinator has already registered the task, so get_task_agent_status will report it as idle with no lastError instead of the startup failure/timeout this new tool is meant to diagnose; mark the registry failed on the ensureBridgeStarted() failure path before returning.
Useful? React with 👍 / 👎.
1 participant
Summary
get_task_agent_statusthrough both desktop tool surfaces so chat can inspect running/completed/failed/timed-out task agentsWhy
The desktop chat can run task-chat agents, but the main/floating chat had no explicit awareness surface for them. When a user asked about “your subagents” after seeing a task-agent timeout, the assistant could plausibly answer that it had no subagents and could not diagnose the timeout.
This gives the assistant a small, local status surface it can query before answering those questions.
Testing
swiftc -parse desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskAgentStatusRegistry.swift desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskChatCoordinator.swift desktop/macos/Desktop/Sources/ProactiveAssistants/Assistants/TaskAgent/TaskChatState.swift desktop/macos/Desktop/Sources/Providers/ChatToolExecutor.swift desktop/macos/Desktop/Sources/Providers/ChatProvider.swift desktop/macos/Desktop/Sources/Chat/ChatPrompts.swiftgit diff --checkNot fully run:
swift buildstarted dependency resolution but timed out after 600s while downloading SwiftPM binary artifacts.npm install && npm run buildcould not complete on this machine because the filesystem ran out of space while installing dependencies.