fix(agent-harness): escalate user-actionable blockers to the user with a concrete ask (#4092)#4482
Conversation
…h a concrete ask (tinyhumansai#4092) When an agent is stuck on something only the user can unblock — the issue's canonical case is acting on a service that isn't connected — the no-progress ladder halts with the crate's generic "the goal looks unreachable in this environment; report this back" summary. That's the wrong framing for a missing connection: it's not an unreachable environment, it's a blocker the user can clear, and the agent should say so with a concrete next step. In `RepeatedToolFailureMiddleware`'s halt path, detect a user-actionable blocker (a missing service connection — the same not-connected signal the composio error mapping already keys on, and which the tools surface as "connect … in Settings → Connections") and replace the generic halt summary with a direct ask: "I can't continue without your input: <tool> needs a service that isn't connected. <relayed tool message> Connect it (Settings → Connections), then tell me to retry — or tell me how you'd like to proceed." The run still pauses so the ask surfaces; non-user-actionable failures keep the crate's summary unchanged. Tests: `user_actionable_escalation` detects a missing connection and phrases the ask (and returns None for plain environment failures); a repeated not-connected failure halts with the user-directed ask (not the generic report-back) and still pauses. Closes tinyhumansai#4092. Claude-Session: https://claude.ai/code/session_01KcmdqJVpjmnH31HqTHRLwG
Unrelated CI unblock (tinyhumansai#4446 golden drift; same fix as tinyhumansai#4475). Claude-Session: https://claude.ai/code/session_01KcmdqJVpjmnH31HqTHRLwG
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 1 minute Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
![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: f20fe17edf
ℹ️ 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".
| let missing_connection = lower.contains("not connected") | ||
| || lower.contains("isn't connected") | ||
| || lower.contains("is not connected") | ||
| || (lower.contains("connect") && lower.contains("settings")); |
There was a problem hiding this comment.
When a repeated Composio insufficient-scope or trigger-permission failure reaches this halt path, its existing error text contains guidance like Reconnect ... in Settings → Connections while explicitly saying the connected account is missing permissions (src/openhuman/composio/error_mapping.rs:155-174). This broad (connect && settings) match rewrites that into “needs a service that isn't connected,” which contradicts the real cause and sends users down the wrong recovery path; please narrow the predicate to true not-connected/platform errors or preserve the original scope/permission wording.
Useful? React with 👍 / 👎.
# Conflicts: # src/openhuman/tinyagents/middleware.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 72ecf82d02
ℹ️ 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".
| // Keep this narrow: some scope/permission failures legitimately tell the | ||
| // user to reconnect in Settings, but they are not missing connections. | ||
| let missing_connection = lower.contains("[composio:error:composio_platform]") | ||
| || lower.contains("not connected") |
There was a problem hiding this comment.
This broad substring also matches agent-actionable MCP errors: mcp_clients_list_tools returns server_id=... is not connected; connect it first via mcp_clients_connect (src/openhuman/mcp_registry/ops.rs), and the tinyagents adapter turns that into a failed tool result. After repeated calls, this new branch replaces that recovery hint with “Connect it (Settings → Connections)”, even though the correct next step is for the agent to call the MCP connect tool, not for the user to reconnect a service in Settings. Please anchor this escalation to true integration/platform connection failures (or preserve errors that already name a recovery tool).
Useful? React with 👍 / 👎.
1 participant
Summary
config_*_privacy_modeto a stale schema-catalog golden — see## Related.Problem
Issue #4092: when an agent is stuck on something only the user can unblock (missing connection, ambiguous request, required confirmation), it should pause and ask the user a specific question instead of looping silently. The canonical example: acting on a service that isn't connected — the agent retries and never says "Service X isn't connected — connect it in Settings, or tell me how to proceed".
On the current base:
graph.rs), so the pure "ask the user" path is covered there.The gap: the halt summary is framed as "the goal looks unreachable in this environment; report this back" — wrong for a missing connection, which is not an unreachable environment but a blocker the user can clear. The agent reports a generic dead-end instead of asking the user to connect the service.
Solution
In
RepeatedToolFailureMiddleware'sHaltarm, detect a user-actionable blocker viauser_actionable_escalation(tool, error)— today a missing service connection, matched on the same not-connected signal the composio error mapping already uses (not connected/connect … in Settings), which the tools themselves emit. When detected, replace the generic halt summary with a user-directed ask that relays the tool's own message and gives a concrete next step (connect in Settings → Connections, then retry, or say how to proceed). The run stillPauses so the ask surfaces. Non-user-actionable failures (a missing file, a segfault) returnNoneand keep the crate's summary untouched.This escalates after the same-strategy retries are exhausted (the "after N unproductive iterations" the issue asks for), turning a generic "I give up" into a specific, actionable ask.
Submission Checklist
user_actionable_escalation_detects_missing_connection(missing-connection → ask; plain failures → None) andhalt_on_missing_connection_asks_the_user_instead_of_reporting_back(a repeated not-connected failure halts with the ask, not the generic report-back, and still pauses).N/A: behaviour change to existing no-progress handling.## Related— N/A.N/A: internal escalation wording.Closes #NNN.Impact
Related
test(ci):change adds the privacy_mode methods to theworker_a_controller_schemas_are_fully_exposedgolden (pre-existing feat(privacy): Privacy Mode + local-only inference enforcement (#4435) #4446 break; also fixed in feat(orchestration): nested contacts → sessions with create + session send #4475).AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
fix/GH-4092-escalate-to-userValidation Run
pnpm --filter openhuman-app format:check— N/A (no frontend changes)pnpm typecheck— N/A (no TS changes)openhuman::tinyagents::middleware::tests::{user_actionable_escalation_detects_missing_connection, halt_on_missing_connection_asks_the_user_instead_of_reporting_back}— execution deferred to CI (shared build host)rustfmt --edition 2021 --checkclean;cargo check --bin openhuman-corepassed (Finished dev)Validation Blocked
command:cargo test --lib -- user_actionable_escalation halt_on_missing_connectionerror:none — shared build host saturatedimpact:cargo checkcompiled clean; deterministic tests validated by CIBehavior Changes
Parity Contract
user_actionable_escalationreturnsNonefor anything but a recognised missing-connection signal, so only that case is reworded.Duplicate / Superseded PR Handling