Improve native tool outcomes and prevent no-progress loops

[SudoJacky]

Summary

• expose structured domain outcomes for web, shell, and MCP tool results
• centralize model guidance and UI summaries from the structured result envelope
• detect browser actions that execute without changing page state
• prevent equivalent external tool calls from repeating after a no-progress result until relevant state changes
• preserve explicit same-call continuations such as shell polling

Why

Browser actions that produced no observable change could previously look successful to the agent. With limited result semantics, the model could repeat the same click indefinitely. Other native tools also returned inconsistent failure and continuation information.

Impact

The model now receives consistent execution status and domain-effect guidance. Repeated calls against unchanged state are returned as a structured repeated_no_progress result and the agent is asked to replan instead of redispatching the tool.

Validation

• cargo test tool_loop_guard --jobs 4
• cargo test agent::runtime::tests::tools --jobs 4
• cargo test agent::runtime::tool_projection::tests --jobs 4
• cargo test agent::runtime::tool_result::tests --jobs 4
• cargo fmt --all -- --check
• git diff --check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 55474f6a5c

ℹ️ 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".

[chatgpt-codex-connector]

Allow transient MCP startup calls to retry

When parallel MCP calls target a fresh server, the first call starts the client while the second receives ServerStarting; by the time the batch returns, that server may already be ready. Mapping this explicitly retryable condition to Replan with no nextAction causes the loop guard to record the call as no-progress and permanently block an identical retry during the turn, so one of the advertised parallel calls cannot be recovered. Treat ServerStarting as retryable with updated state or otherwise exempt it from the no-progress guard.

Useful? React with 👍 / 👎.