611 Commits

Author	SHA1	Message	Date
Gabe Milani	26518e0dec	fix(flow): report the real CEL error for failures inside map literals (#6793)	2026-08-03 19:47:02 +00:00
João Moura	766d71aefb	feat: surface AMP in AGENTS.md and detect coding agents in telemetry (#6779)	2026-08-03 12:13:05 -07:00
João Moura	f262ac214e	feat: bump versions to 1.15.10 (#6753)	2026-07-31 14:45:28 +00:00
João Moura	ebe0082aca	feat(tracing): collect skill usage events (#6727) ... * feat(tracing): collect skill usage events PR #6652 added SkillUsedEvent but deliberately shipped no listener wiring, so the event reached no collector. The trace listener subscribed to the five setup events -- discovery, load, activation, failure -- and none of them can answer the question skills observability is for: activation is idempotent and fires once at setup, so an agent using a skill across twenty turns produces exactly one event. SkillUsedEvent is the only runtime signal and the only one that re-fires per execution. Subscribing to it lets a trace attribute skill usage to an agent and a task. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): scope the trace-listener handlers, assert the forwarded event CrewAIEventsBus is a singleton, so constructing one in the fixture still registered against the process-wide bus. _register_action_event_handlers attached every action handler with no cleanup, leaving them live after the patch ended -- firing against a listener built with __new__, which has no batch_manager, in whatever test ran next. scoped_handlers clears them. Also assert the event object itself is forwarded, not just its type: the collector serializes the event, so dropping or replacing it would lose every attribution field while still passing a type-only check. Both raised in review on #6727. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test: assert the forwarded skill event by identity Comparing field values would still pass if a handler forwarded a reconstructed copy rather than the event itself. Bind the event and assert `forwarded is event`. Raised in review on #6727. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 18:17:13 +00:00
João Moura	bfe8df4471	feat: bump versions to 1.15.9 (#6725)	2026-07-29 22:40:32 -07:00
João Moura	453676c61a	feat(tools): surface tool failures instead of reporting them as success (#6712) ... * feat(tools): surface tool failures instead of reporting them as success A tool can finish without raising and still fail to do what it was asked. Slack answers HTTP 200 with `{"ok": false, "error": "channel_not_found"}`; an MCP server sets `isError`; a CrewAI AMP action returns `API request failed: ...`. In every case the call "worked", so the error text reached the agent as an ordinary result, the agent narrated the problem in prose, and the run was recorded as a success. Concretely: five failed `slackbot_send_message` calls each rendered as "Tool Execution Completed", the task passed, and the crew passed -- with the only evidence being a sentence in the final answer. Nothing downstream could tell the difference, and an agent that keeps going on a step that silently did nothing builds the rest of its work on it. Give that outcome a type and a reaction: - `ToolFailure` -- what a tool returns instead of an error string. The agent still reads prose via `as_agent_message()`, so model behavior is unchanged; the framework now knows the call failed. - `ToolFailurePolicy` -- `ignore` (previous behavior), `warn` (default: record + emit, keep going), `raise` (abort with `ToolExecutionFailedError`). Resolved most-specific-first: tool, task, agent, crew. - `ToolFailureDetectedEvent` -- emitted before a `raise` aborts, so subscribers always observe the failure. `ToolUsageFinishedEvent` also carries a `failure` field so a trace UI can mark the call failed without correlating two events. - `tool_failures` on `TaskOutput`, `CrewOutput` and `LiteAgentOutput`, plus `has_tool_failures`, so consumers never parse a string. Detection is strictly declarative -- no string sniffing, so a tool that legitimately returns text about an error is never misread as failing. Failures come from a returned `ToolFailure`, a raised exception, MCP `isError`, a spent `max_usage_count`, or an unknown tool. Wired into all four tool-execution paths (the ReAct path and the three native function-calling implementations). Sources updated to report structurally: `MCPClient.call_tool_result()` preserves `isError` that `call_tool()` dropped, and `CrewAIPlatformActionTool` returns a `ToolFailure` for non-2xx and for caught exceptions. Two latent bugs fixed along the way: `ToolUsage` assumed every agent has a `fingerprint` (LiteAgent does not), and policy resolution now tolerates malformed values rather than letting telemetry take down a tool call. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): address review round 1 on tool-failure signalling Five real defects from Bugbot, none of them cosmetic. Tool-scoped policy never applied (high). `resolve_tool_failure_policy` read `tool_failure_policy` off the object handed to it, but every execution path passes the `CrewStructuredTool` wrapper, which never carried the attribute -- and `BaseTool` never declared it in the first place. A tool-scoped `raise`/`ignore` was silently ignored while the docs and a unit test claimed otherwise; the test passed only because it called the resolver directly with an authored tool. Declared the field on `BaseTool`, propagated it through `to_structured_tool()` and `CrewStructuredTool`, and made resolution fall back through `_original_tool` so either shape works. A failed call still printed the green "Completed" panel, then the red one. That is the terminal version of the exact bug this PR is about. Suppressed the success panel when the call reported failure. A raised tool printed twice: `ToolUsageErrorEvent` already renders a red panel, and the new failure panel repeated it. The event is still emitted -- policy and traces need it -- but the duplicate console output is gone. Both decisions now live in named predicates on `ConsoleFormatter` rather than inline in the listener closure, so they are directly testable. Unknown tools were reported on the ReAct path but silently ignored on all three native paths, so the same miss was loud or silent depending on executor style. Native paths now record `UNKNOWN_TOOL` too. This also surfaced a live `NameError`: ruff had pruned `ToolFailureReason` from `agent_utils` as unused, so the new branch would have crashed at runtime. `LiteAgentOutput` had `tool_failures` but not `has_tool_failures`, which the PR promised on all three output types -- an `AttributeError` for any caller sharing one check across result types. Testing: 16 further tests, 45 total. Two console tests were passing vacuously because `emit()` dispatches sync handlers on a thread pool, so the assertions raced the handler; they now assert on the predicates directly, and the native-path test drains the bus with `flush()` and checks the synchronously-written record. Full suite still matches baseline exactly at 377 pre-existing failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * chore: update tool specifications * fix(tools): address review round 2 and fix CI type failure CI caught a type error I should have: widening `agent` to accept a `LiteAgent` (so a standalone LiteAgent resolves its own policy) left the declared signatures behind. Widened `execute_tool_and_check_finality`, its async twin, and `ToolCallHookContext` to `Agent | BaseAgent | LiteAgent | None`, which is what those actually receive now. Seven CodeRabbit findings, all verified against the code first: `raise` was being downgraded by three enclosing handlers. With `max_execution_time` set, `_execute_with_timeout` wrapped every exception in `RuntimeError`, so `_check_execution_error` no longer recognized the passthrough and sent the task through the retry loop instead of aborting. `StepExecutor.execute` turned it into `StepResult(success=False)` and let the plan continue. `LiteAgent.kickoff` ran it through `handle_unknown_error` and printed "This is likely a bug - please report it" for what is a deliberate, configured stop. Failure records were dropped on two paths. `reset_tool_failures()` only ran in `_prepare_task_execution`, so `Agent.kickoff()` / `kickoff_async()` — which enter through `_prepare_kickoff` — accumulated records across runs. And a guardrail retry calls `execute_task` again, which resets the agent, so a tool that failed on a blocked attempt vanished from the final output entirely: a run could report zero failures having demonstrably failed one. Failures now accumulate across guardrail attempts. Writing the tests for that surfaced a further miss of my own: `Agent.kickoff()` builds its `LiteAgentOutput` in `agent/core.py` via `AgentExecutor`, not through `LiteAgent`, so `tool_failures` was always empty there regardless of the recording fix. Wired up, and the LiteAgent path now reads from whichever agent the executor was handed (`original_agent` under kickoff, `self` standalone) rather than assuming. `last_tool_failures` returns a copy, so a caller cannot mutate the agent's record or watch it shift mid-run. Testing: 7 further tests, 52 total, covering the timeout wrapper, the retry limit, kickoff reset, the kickoff output path, copy semantics and guardrail accumulation. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): make crew-scoped policy real and close the last raise leak Two findings, and the first was a documented feature that never worked. `resolve_tool_failure_policy` consulted a crew, and the docs advertised crew as a scope, but `Crew` had no `tool_failure_policy` field at all -- and even with one it was unreachable, because `BaseAgent` defaulted the policy to `WARN` rather than `None`, so resolution always stopped at the agent. Crew-level configuration was silently ignored. Fixed by making "inherit" the default everywhere instead of baking `warn` into one layer: `Crew` gains the field, and `BaseAgent`/`LiteAgent` default to `None` like `Task` and `BaseTool` already did. The resolver owns the single fallback, so the chain is genuinely tool > task > agent > crew > warn and the effective default with nothing configured is still `warn`. Reading `agent.tool_failure_policy` now returns `None` (meaning "inherit") rather than `WARN`. The other: `StepExecutor` re-raised `ToolExecutionFailedError` from its outer handler, but the nested handler around the native-to-text tooling fallback still caught it and returned `StepResult(success=False)`. An agent whose LLM lacked native tool calling would therefore not abort under `raise`. That is the third distinct place this exception was being downgraded; it now re-raises there too. Testing: 8 further tests, 60 total, including the full precedence chain walked one level at a time and crew-scoped `raise`/`ignore` driven end-to-end through `kickoff()` rather than only through the resolver -- the gap that let the original crew bug pass review. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * docs: trim comments and docstrings on tool-failure signalling Prose only -- no behavior change. Cut the module docstring, the longer class and method docstrings, the multi-line inline comments, and the verbose Field descriptions down to what actually earns its place. Net 87 lines lighter. Kept the "why" in every case where the reason is non-obvious (why the event fires before a raise, why the policy reads through the tool wrapper, why the bus needs draining in tests) and dropped the restatements of what the code already says. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): make ignore truly silent, stop caching failures, close 4 gaps Six findings from the latest review round, all verified against the code before touching it. `ignore` was not silent. `ToolUsageFinishedEvent.failure` was set before the policy ran, so traces still saw a failed call under a policy documented as surfacing nothing. Worse, the console then showed *no* panel at all: green was suppressed because `failure` was present, red was skipped because `ignore` never emits `ToolFailureDetectedEvent`. New `reportable_failure()` resolves the policy before the finished event and drops the flag under `ignore`; wired into all four execution paths. Failures were being cached. `CacheHandler.add` stored a `ToolFailure` like any other result, so a transient error became permanent for the rest of the run and every later hit re-reported a call that never re-ran. The cache now refuses to store declared failures -- fixed at the single choke point rather than at each of the four call sites. A spent `max_usage_count` was invisible on the shared native path. `BaseTool._claim_usage` returned a bare string that only the executors recognising that exact message treated as a failure. It now returns a `ToolFailure` with `USAGE_LIMIT`, so every path records it. A guardrail returning a whole `TaskOutput` replaced the output without carrying accumulated failures over, so earlier attempts vanished from `CrewOutput.tool_failures`. New `merge_tool_failures()` combines and deduplicates, and the retry-rebuild path uses it too. A hook-blocked call inherited a cached failure and attributed it to a call that never ran. Now cleared. Not reachable through the built-in cache once failures stop being cached, so the test injects a custom cache handler that does retain them -- verified to fail without the guard. Also removed a `datetime` import left unused by the earlier console-test rewrite. Testing: 13 further tests, 73 total. Full suite matches baseline exactly at 377 pre-existing failures; the usage-limit suites that `_claim_usage` touches pass unchanged; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): let raise through the parallel native path, guard all handlers Chasing down CodeRabbit's note about callers of execute_single_native_tool_call turned up a fifth place this exception was being downgraded: the experimental executor's parallel branch wrapped future.result() in a broad except and folded the abort into a fake tool result, so the remaining parallel calls carried on. The sequential path and crew_agent_executor's parallel branch were already fine. Five separate handlers have swallowed this during review, so added a guard test asserting the passthrough at every site rather than trusting the next one gets spotted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): keep a failed tool out of the final answer, finish crew scope Three more findings, all confirmed against the code. A failed `result_as_answer` tool still became the task's output. The native paths already excluded raised errors and hook blocks from short-circuiting, but not declared failures -- so an error message silently became the answer, which is the exact shape of bug this PR exists to prevent. Fixed on all paths, and there were three independent override points, not one: `ToolResult.result_as_answer` in tool_utils, the `execution_result` finality checks in both executors, and `process_tool_results()`, which reads `agent.tools_results` back separately. The first two fixes alone left the behavior unchanged; only the third made the test pass. `ToolUsage` never received a crew, so a crew-level `ignore` half-applied: recording and `ToolFailureDetectedEvent` stayed quiet, but the flag was still attached to `ToolUsageFinishedEvent`. It now takes and stores `crew`. `CrewAgentExecutor.invoke`/`ainvoke` routed a deliberate stop through `handle_unknown_error`, printing "An unknown error occurred" on verbose runs. LiteAgent already special-cased this; both now do. Testing: 5 further tests, 79 total, including that a *successful* `result_as_answer` tool still short-circuits. Full suite matches baseline exactly at 377 pre-existing failures; mypy clean on every changed file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): report malformed tool args, correlate the failure event Two findings from the latest round. Malformed native tool arguments returned early with a plain error dict and never reported a failure, so `ToolFailureReason.INVALID_INPUT` was declared but unreferenced -- a bad tool call was absent from records, events and `raise` aborts. `parse_tool_call_args` now carries an INVALID_INPUT failure on the error dict and both executors report it before returning. `ToolFailureDetectedEvent` never set `agent_id`, so a trace could not tie it to a specific agent instance. Fixing that exposed the same gap running the other way: `ToolUsage`'s own started/finished/error events never set `agent_id` either, so on the ReAct path the paired finished event had nothing to correlate against. Both now set it. Set explicitly rather than via `from_agent`, which would also overwrite `agent_role` and lose the `_original_role` preference those events already apply -- a behavior change that has nothing to do with correlation. Testing: 5 further tests, 84 total, asserting the ids match between the failure event and its paired finished event. One existing test pinned the exact key set of the parse-error dict and was updated for the new key. Full suite matches baseline at 377 pre-existing failures; the one apparent addition was the known `test_trace_enable_disable` order-flake, confirmed by re-running rather than assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): scope failure accumulation per execution, drop deprecated executor Two review requests from @lorenzejay. Accumulation no longer lives as mutable state on the shared agent. A ContextVar collector is opened around each execution -- task, kickoff, and each guardrail retry -- and the output reads that collector directly instead of copying the agent's list. ContextVars are copied per asyncio task and per thread, so concurrent executions cannot see each other's records, and nesting is safe for retries. `last_tool_failures` prefers the active collector and falls back to the last completed execution, so the accessor is correct during a run too. The per-execution reset that caused the erasure is gone. Reproducing this took some digging and the finding is worth recording: crew tasks *cannot* hit it, because `AgentExecutor` refuses concurrent reuse of one instance and raises. `agent.kickoff()` has no such guard, and there the bug reproduces exactly as reported -- two concurrent kickoffs each returned two records. The regression test forces the overlap with a barrier so it is deterministic rather than timing-dependent, and I verified it reports [2, 2] against the old behavior and [1, 1] now. Removed the tool-failure integration from `CrewAgentExecutor` entirely; that file is back to its state on main. Note the shared ReAct helper it calls still records failures, since that is common code rather than new behavior in the deprecated file -- so a `raise` policy will be swallowed by that executor's generic handler. Flagged on the PR rather than papered over. Testing: 89 total. Two tests I wrote for this were vacuous on the first attempt -- they passed against the simulated pre-fix code -- so each concurrency test was checked against the old behavior before being kept. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): report malformed calls everywhere, drop the unused block reason Four findings. `execute_single_native_tool_call` swallowed a JSON decode error into an empty args dict and ran the tool with no input at all -- worse than not reporting it. It now routes through `parse_tool_call_args` like the executors do, so the StepExecutor/planning path reports INVALID_INPUT and returns instead of executing. That also removes a duplicated inline parse. The ReAct path returned a `ToolUsageError` message as an ordinary result without reporting it, so a malformed call there was invisible while the equivalent native failure was recorded. Now reported as INVALID_INPUT too. `Agent.kickoff` opened a collector but no longer reset the agent-level list, so `last_tool_failures` grew across kickoffs. Reset restored, matching task execution. `ToolFailureReason.BLOCKED_BY_HOOK` was declared and never produced. Rather than start reporting hook blocks as failures, the member is removed: a block is a deliberate decision by the hook author, and treating it as a failure would make `raise` abort on an intentional veto. Added a guard test that every remaining reason is actually produced somewhere, so a dead member cannot reappear -- the same smell that flagged INVALID_INPUT last round. Also switched the deprecation guard test to a single import style. Testing: 6 further tests, 95 total, including that the tool does not run when its args fail to parse. Full suite matches baseline at 377 pre-existing failures; mypy clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG * fix(tools): merge failures across kickoff guardrail retries, cancel siblings Kickoff guardrail retries discarded the blocked attempt's failures. Each retry calls `_execute_and_build_output`, which opens a fresh collector and builds a new output, so a run could report zero failures having demonstrably failed one -- the same bug already fixed on the task guardrail path, which merges. Now merged there too. Verified the test fails without the fix. Under `raise`, one parallel native tool aborting left its siblings running: the pool waited for them and pending ones still started. It now shuts the pool down with `cancel_futures=True` so a not-yet-started sibling never runs. Threads already in flight cannot be interrupted in Python, so a concurrent tool may still complete before the abort surfaces; that is noted at the call site rather than left implied. Also satisfied CodeQL by materialising the enum in the guard test's loop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ETacm2dMASfpMAYUiDu5YG --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-07-29 19:30:14 -07:00
Lucas Gomide	d52d0a1628	feat: emit FlowFailedEvent when a flow execution fails (#6718) ... * feat: emit FlowFailedEvent when a flow execution fails A failed flow never emitted a terminal lifecycle event, so the `flow_started` scope stayed open and consumers such as tracing closed the root span with a generic orphaned message instead of the real error. `kickoff_async` and the resume path now emit `FlowFailedEvent`, paired with `flow_started` and carrying the exception, after draining pending handlers and background memory writes. The resume path also emits the `MethodExecutionStartedEvent` it was missing for the method being resumed, so its finished or failed event pairs with its own scope instead of popping the flow's. * fix: skip FlowFailedEvent when the run never opened a scope The `kickoff_async` try block starts before `FlowStartedEvent` is emitted, so an abort in the execution-start hooks, in input handling or in state restore emitted a `flow_failed` with no opener, which pops an unrelated scope and warns about an empty scope stack. The failure event is now gated on the flow scope actually being open, either from this kickoff's `flow_started` or from a restored deferred session scope.	2026-07-29 14:44:55 -04:00
Lorenze Jay	f15844b219	Lorenze/imp/skills progressive disclosure (#6675) ... * skills progressive disclosure * skills progressive disclosure * improving progressive disclosure * addressed comment * fix test --------- Co-authored-by: João Moura <joaomdmoura@gmail.com>	2026-07-28 09:33:43 -07:00
João Moura	133baf39b8	feat: bump versions to 1.15.8 (#6702)	2026-07-28 14:59:36 +00:00
João Moura	38ca5edce2	feat: bump versions to 1.15.7 (#6672)	2026-07-26 18:07:46 +00:00
Lorenze Jay	c459d01c35	feat: bump versions to 1.15.7a1 (#6661)	2026-07-26 13:47:11 -03:00
João Moura	cc0759854d	fix(skills): resolve registry skills through the runtime's CrewAI+ client (#6658) ... * fix(skills): resolve registry skills through the installed AMP client Skill downloads built their own `PlusAPI` and authenticated it from `CREWAI_USER_PAT`, the platform integration token, or the saved CLI login. Managed runtimes have no user credential to offer: they install a client of their own, which `load_agent_from_repository` already resolves through, so Agent Repository lookups worked while the skill downloads beside them failed with 401. Skills now resolve their client the same way, via `resolve_plus_client()` next to the hook it reads. A client that can't fetch skills falls back to environment credentials and warns, so older runtimes behave as they do today. `resolve_plus_response()` shares the sync/async bridging both lookups need, since `PlusAPI` is synchronous while managed clients are not. Version pinning, which the same bug was hiding: - Registry refs accept `@org/name@version`, and `@org/name@v1.2.0` since people write it both ways. `parse_skill_ref()` returns a `SkillRef(org, name, version)`; `parse_registry_ref()` keeps its `(org, name)` shape and drops the pin, so existing callers are unaffected - Agent Repository agents record a version per skill, which was parsed off the response and dropped. Those pins now travel with the refs, so publishing a new version of a skill no longer changes every agent that uses it - A pinned ref only accepts a project-local copy declaring that version in its `metadata.version` frontmatter, and the cache reports a miss when the version it recorded differs — so a pin re-resolves rather than loading another version. Unpinned refs keep hitting the cache as before - An unknown pin fails instead of quietly falling back to the newest version Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(skills): reject a blank version pin instead of floating to latest A blank `version` passed to `download_skill` read as "unpinned" and quietly resolved the latest version, which is not what a caller supplying one asked for — and it disagreed with `parse_skill_ref`, which already rejects empty pins. Not reachable through `resolve_registry_ref` or the Agent Repository auto-pinning, both of which only ever pass a non-empty version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(skills): carry the caller's context into the worker thread When resolve_plus_response bridges an async client from inside a running loop it runs the coroutine on a worker thread, which starts with empty ContextVars. A client reading runtime state there — the platform integration token, flow context — would see defaults rather than the caller's values, which is hard to diagnose from the resulting auth or routing failure. Copy the context across, matching how the parallel-summarization bridge in this module already does it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 13:27:29 -03:00
alex-clawd	bd2cb0f23e	fix(openai): recover from the GPT-5.6 tools + reasoning_effort 400 (#6660) ... An ordinary agent with a tool fails on the whole GPT-5.6 family: Agent(role=..., goal=..., backstory=..., llm=LLM(model="openai/gpt-5.6-sol"), tools=[multiply]) Function tools with reasoning_effort are not supported for gpt-5.6-sol in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'. Nothing sets reasoning_effort -- not the user, not CrewAI. The family applies a server-side default and then refuses it once tools are present. Confirmed with raw HTTP, no CrewAI involved, on a payload with no reasoning_effort key at all: gpt-5.6-sol tools, no reasoning_effort key -> 400 gpt-5.6-sol tools, reasoning_effort="none" -> OK gpt-5.5 tools, no reasoning_effort key -> OK gpt-5.4 tools, no reasoning_effort key -> OK gpt-5.2 tools, no reasoning_effort key -> OK So this is GPT-5.6 only, and it needs an explicit "none" -- dropping the key is what the rejected request already looked like. Recovered from the error rather than a model list: catch the 400, resend with reasoning_effort="none", once. No model names, so a family OpenAI restricts later works without a release here. Detection matches the structured `param` field plus the message, so the unrelated "Unsupported value" 400 that o1/o3 return for "none" isn't mistaken for this one, and the retry can't loop. Verified against main with real agents (no reasoning_effort anywhere): model no tools tools tools + reasoning=True gpt-5.6-sol ok / ok 400 / ok hang / ok gpt-5.6-terra ok / ok 400 / ok - / ok gpt-5.6-luna ok / ok 400 / ok - / ok gpt-5.5 ok ok - gpt-5.2 ok ok ok / ok gpt-4o ok ok - On main, tools + Agent(reasoning=True) produced no output and no error and was killed at 420s; gpt-5.2 with the same config finishes in ~40s. Both the 400 and that hang are fixed. Tests: 15 cases, including agent definitions with tools, with tools plus reasoning=True, and without tools. tests/llms + tests/agents -> 961 passed (1 pre-existing unrelated failure from a local OLLAMA_API_KEY env leak). Ruff + mypy clean.	2026-07-26 12:48:17 -03:00
alex-clawd	c52d0d9530	fix(openai): make tool calling work on the Responses API path (#6657) ... * fix(openai): make tool calling work on the Responses API path An agent with tools on api="responses" never produced an answer. It returned the raw tool-call list instead: [{'id': 'call_...', 'name': 'multiply', 'arguments': '{"a":17,"b":23}'}] Three defects in the chain, all on the Responses side only: 1. `is_tool_call_list()` knew the OpenAI-nested, Anthropic, Bedrock and Gemini shapes but not the Responses one ({"id", "name", "arguments"} -- no nested "function", no "input"). The list wasn't recognized as tool calls, so the executor handed it back verbatim as the final answer. 2. `extract_tool_call_info()` read "arguments" only from a nested "function" object, falling back to "input". For the Responses shape both missed and the arguments silently became {}, so the tool would have run with no input. 3. With those fixed the tool ran, then the follow-up request 400'd: Invalid type for 'input[1].content': expected one of an array of objects or string, but got null instead. Tool calling is expressed differently by the two APIs. Chat Completions uses an assistant message carrying `tool_calls` with content: None, then role: "tool" results. The Responses API uses flat function_call / function_call_output items keyed by call_id. Those messages were passed through untranslated. `_to_responses_input()` now converts them. Messages without tool calls pass through unchanged, so nothing else moves. Verified end to end against the live API: api="responses" + tools -> 391 (was raw tool-call JSON) chained multi-step tool calls -> 400 (17*23, then +9) completions path (control) -> 391 (unchanged) The generated `input` payload was also posted to /v1/responses directly and accepted, and the pre-fix chat-shaped payload confirmed as a 400. This is why api="responses" never worked for agents: the provider side has had a full Responses implementation since #4258/c4c9208, but the executor never learned the shape it emits. Fixing it also unblocks routing gpt-5.4+ tool calls to the Responses API instead of dropping reasoning_effort. Tests: 12 cases covering recognition, extraction (including that the Chat Completions and Bedrock shapes are unaffected), translation of assistant/tool messages, parallel calls, assistant text alongside tool calls, non-string tool output, and the full prepared `input` list. * fix(openai): prefer Responses "call_id" over the item's own "id" Per CodeRabbit review. A raw Responses function_call item carries both keys with different values, confirmed against the live API: keys ['arguments', 'call_id', 'id', 'name', 'status', 'type'] id fc_0adeb715c5d740c7006a65ccb72b948199872ad8b5a5c53108 call_id call_dEoHFrYnOgWYvk17FymdcDZ5 function_call_output must reference call_id. Reading the item's own "id" would produce a tool result the model can't correlate back to its invocation. Our own _extract_function_calls_from_response already maps item.call_id into "id", so the normal path was correct and the existing tests passed. But extract_tool_call_info is a shared helper reached from every provider's tool loop, and a raw Responses item is a plausible thing to hand it -- silently picking the wrong identifier is a bad trap to leave in place for one line of guard. Tests: raw item extraction asserting call_id is chosen over id, and a round-trip check that the id extracted from a call is the one sent back with its result. 997 passed across tests/llms, test_agent_utils and tests/agents (1 pre-existing unrelated failure from a local OLLAMA_API_KEY env leak). Real two-agent chained-tool run still returns the correct answer. --------- Co-authored-by: João Moura <joaomdmoura@gmail.com>	2026-07-26 06:18:20 -03:00
alex-clawd	b64c92c87b	fix(openai): route responses-only models instead of failing with 404 (#6656) ... The pro tier is not served by /v1/chat/completions. Probing the live endpoints: model /v1/chat/completions /v1/responses gpt-5-pro 404 OK gpt-5.5-pro 404 OK gpt-5.4-pro 404 OK gpt-5.2-pro 404 OK o1-pro 404 OK o3-pro 404 OK Since api defaults to "completions", LLM(model="openai/gpt-5-pro") fails with "Model ... not found", which is misleading -- the model exists, the endpoint is wrong. OpenAI's own 404 text ("This is not a chat model") doesn't make the fix obvious either. These requests now route to the Responses API automatically, which is verified to work for every model above. An explicit api= setting is always honoured. Model matching normalizes the configured string first, so "openai/gpt-5-pro" and "gpt-5-pro-2025-10-06" both resolve to "gpt-5-pro". It's an exact list rather than a "-pro" substring, so a custom deployment named "gpt-4-pro-custom" isn't swept up. The chat-completions 404 handler also gained an actionable message: when the response says responses-only, or the model is a known pro model, the error names api="responses" instead of just reporting "not found". Tests: 29 cases covering name normalization, detection, routing (including that call() reaches the Responses handler), and both 404 message paths.	2026-07-26 06:03:09 -03:00
alex-clawd	80fa0295c4	Emit skill usage events at runtime for observability (#6652) ... * feat: emit skill usage events at runtime * test: cover skill events via execute_task paths	2026-07-26 05:04:19 -03:00
alex-clawd	728183e420	fix(deps): bump bedrock-agentcore to patch CVE-2026-16796 (#6654) ... bedrock-agentcore 1.7.0 has GHSA-j6g5-3hh3-pgw8 (CVE-2026-16796, high): argument-delimiter injection in CodeInterpreter.install_packages(). It fails the pip-audit vulnerability scan on every PR in the repo. The patch is 1.18.1, which requires boto3>=1.43.31. The old <1.8.0 cap plus aiobotocore~=3.5.0 (botocore<1.42.92) made that unsatisfiable, so the AWS stack moves together: - bedrock-agentcore >=1.7.0,<1.8.0 -> >=1.18.1,<2.0.0 - boto3 ~=1.42.90 -> ~=1.43.46 (aws + bedrock extras) - aiobotocore ~=3.5.0 -> ~=3.8.0 (aws + bedrock extras) aiobotocore 3.8.0 allows botocore <1.43.47 and boto3 1.43.46 pins botocore 1.43.46, so the ranges overlap. Verified: uv lock resolves, pip-audit reports no vulnerabilities (3 existing ignores, none new), 48 bedrock tests pass, and both bedrock toolkits import cleanly. BrowserClient.{start,stop,generate_ws_headers} and CodeInterpreter.{start,stop,invoke} are unchanged in 1.18.1.	2026-07-26 04:55:05 -03:00
Lorenze Jay	a4cbeacca5	feat: bump versions to 1.15.6 (#6631)	2026-07-24 20:21:58 +00:00
alex-clawd	c528e8bdee	fix: detect Anthropic preview tool-use blocks (#6629) ... * fix: detect anthropic preview tool-use blocks * fix: preserve typed Anthropic tool-use blocks * fix: bump gitpython for vulnerability scan * docs: clarify gitpython advisory ranges --------- Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-07-24 15:32:38 -03:00
alex-clawd	c06043f7e8	fix: preserve strict tool schema property names (#6628)	2026-07-24 09:49:05 -07:00
Rip&Tear	b14d36bfe4	chore: bump json-repair to 0.60.1, drop fixed vuln ignores in scan (#6612) ... * chore: bump json-repair to 0.60.1 and un-ignore fixed vulns in scan - json-repair 0.25.3 -> 0.60.1 (fixes GHSA-xf7x-x43h-rpqh) - pyOpenSSL already at 26.2.0 in lock (covers CVE-2026-27448, CVE-2026-27459) - remove the corresponding --ignore-vuln flags from vulnerability-scan.yml * fix: adapt _safe_repair_json to json-repair 0.60 semantics json-repair >= 0.60 returns an empty string for plain-text input and wraps brace-enclosed junk in a single-element list instead of the old ""/{} sentinel values. Treat both as unrepairable so the original tool input is preserved. * chore: fix CI - bump gitpython/pyasn1, drop stale type ignores - gitpython 3.1.50 -> 3.1.52 (GHSA-2f96-g7mh-g2hx, GHSA-v396-v7q4-x2qj, GHSA-956x-8gvw-wg5v; fixed in 3.1.51) - pyasn1 0.6.3 -> 0.6.4 (GHSA-8ppf-4f7h-5ppj, GHSA-hm4w-wwcw-mr6r) - json-repair 0.60 ships type stubs; remove now-unused type: ignore[import-untyped] comments flagged by mypy	2026-07-22 16:47:33 -07:00
Lucas Gomide	3bb87532da	fix: dispatch execution_end hook on failed crew and flow executions (#6607) ... * fix: dispatch execution_end hook on failed crew and flow executions The `execution_end` interception point only fired after a successful kickoff, so consumers never learned about failed runs. Crew kickoff paths (`kickoff`/`akickoff`) and the flow runtime (`kickoff_async`, `resume_async`) now dispatch it on the failure path too, with new additive `status` ("completed"/"failed") and `error` fields on `ExecutionEndContext`. Pairing flags guarantee exactly-once dispatch, keep the start/end pairing invariant, and the original exception propagates unchanged. * fix: track execution_end pairing per invocation for reentrant flows Reentrant kickoffs on the same Flow instance are supported (usage aggregation already accommodates them), but the instance-level pairing booleans let an inner kickoff's completion mark the outer execution as ended, skipping the outer failure's `execution_end`. The pairing state now lives in each `kickoff_async` invocation's locals, and the resume path passes a per-invocation holder into `_resume_async_body`. Crew keeps its instance flags since crew kickoffs are not reentrant on the same instance (`kickoff_for_each` copies the crew).	2026-07-21 15:25:06 -04:00
iris-clawd	6d496f799b	fix: handle async get_agent in load_agent_from_repository (#6608) ... * fix: handle async get_agent in load_agent_from_repository The enterprise PlusClient.get_agent() is async, but load_agent_from_repository() calls it synchronously. When the enterprise client is hooked in, client.get_agent() returns a coroutine instead of a response, causing "'coroutine' object has no attribute 'status_code'". This adds an inspect.isawaitable() check after the call: if the response is a coroutine, it is properly awaited via asyncio.run() (or via a thread-pool executor if an event loop is already running). Co-authored-by: Joe Moura <joao@crewai.com> * fix: resolve mypy type-checker errors for async awaitable handling * fix: remove unused type: ignore comment --------- Co-authored-by: Joe Moura <joao@crewai.com>	2026-07-21 15:21:41 -03:00
Lorenze Jay	40279e3152	fix dep resolution (#6605)	2026-07-21 08:37:08 -03:00
Vinicius Brasil	4c7e483936	feat: bump versions to 1.15.5 (#6601)	2026-07-20 16:20:33 +00:00
Vinicius Brasil	fa255387a3	Authenticate skill registry downloads (#6600) ... Registry downloads initialized PlusAPI without credentials, so uncached skills failed outside CLI-authenticated flows and were blocked entirely in non-interactive environments. Use CREWAI_USER_PAT first, then the platform integration token, then the saved login token, and pass CREWAI_ORGANIZATION_UUID. Remove the non-interactive cache-only restriction so runtime downloads work.	2026-07-20 12:43:03 -03:00
Vinicius Brasil	e0bd967484	feat: bump versions to 1.15.4 (#6582)	2026-07-17 14:27:15 +00:00
João Moura	f0704ebb22	feat(skills)!: promote Skills Repository out of experimental (#6579) ... * feat(skills)!: promote Skills Repository out of experimental The registry-backed Skills Repository (crewai skill create/publish/ install/list, @org/name refs, global cache) is now mainline: - CLI: `crewai skill ...` is a top-level group; the CREWAI_EXPERIMENTAL gate and the now-empty `crewai experimental` group are removed. - Runtime: registry.py, cache.py, and events.py move from crewai.experimental.skills into crewai.skills next to the loader; the require_experimental_skills() gate is gone. crewai.experimental.skills remains as a deprecated re-export shim. - Docs: concepts/skills now leads with the CLI workflow and documents the create -> publish -> install lifecycle. Linear: n/a (requested promotion) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(skills): org-scoped publish only + docs in all languages Skills are always scoped to the publishing organization, like tools: drop the --public/--private flags from `crewai skill publish` and always send is_public=False to the registry. CLI tests assert the flag is rejected and the API never receives a public publish. Translate the new CLI-first Quick Start and the create -> publish -> install lifecycle section into ar, pt-BR, and ko concepts/skills docs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): address review comments on the promotion PR - Back-compat shim now aliases the old submodules in sys.modules so `crewai.experimental.skills.registry/cache/events` imports (and patch targets) resolve to the real crewai.skills modules, not just the package-root re-exports. - `crewai skill publish` actually enforces the git-state check that --force claims to skip: unsynced repos block publishing (mirroring tool publish); standalone skill dirs outside any git repo publish without a check. - Explicit UTF-8 encoding on SKILL.md and cache-metadata reads/writes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): fail closed when git state cannot be validated on publish Follow deploy's pattern: construct git.Repository(fetch=False) and only treat "not a Git repository" as skippable — any other git error (fetch/auth/misconfiguration) now blocks publish with a --force escape hatch instead of silently bypassing the sync check. Also single-style imports in the shim test (CodeQL) with the dotted shim import covered via importlib. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): fetch before sync check on publish; bump mcp past advisories Publish now refreshes remote-tracking refs (repository.fetch()) before is_synced(), so ahead/behind is judged against the actual remote rather than stale local refs; a failing fetch blocks publish with the --force escape hatch. Adds a fail-closed test for fetch errors. Raise mcp to >=1.28.1,<2 (locks 1.28.1): the ~=1.26.0 pin blocked GHSA-hvrp-rf83-w775 / GHSA-jpw9-pfvf-9f58 (fixed 1.27.2) and GHSA-vj7q-gjh5-988w (fixed 1.28.1), which were failing pip-audit on this PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Vinicius Brasil <vini@hey.com>	2026-07-17 14:21:15 +00:00
Vinicius Brasil	4e23bf6d45	Update dependencies with security fixes (#6580) ... * Pillow 12.1.1 → 12.3.0 (CVE-2026-55798, CVE-2026-54059, CVE-2026-54060, CVE-2026-55379, CVE-2026-55380, CVE-2026-59197, CVE-2026-59203) * mcp 1.26.0 → 1.28.1 (CVE-2026-59950) * couchbase 4.3.5 → 4.6.0	2026-07-17 09:12:45 -03:00
Vinicius Brasil	cbb8c982f8	feat: bump versions to 1.15.3 (#6576)	2026-07-16 19:26:14 +00:00
Vinicius Brasil	a1021de7f3	feat: bump versions to 1.15.3a2 (#6573)	2026-07-16 15:43:38 -03:00
Lucas Gomide	9a49af098b	fix: sync kickoff-completed event with OUTPUT hook result (#6571) ... * fix: sync kickoff-completed event with OUTPUT hook result `CrewKickoffCompletedEvent` still carried the pre-hook `TaskOutput`, so AMP/OTEL consumers never saw `OUTPUT` mutations even though the returned `CrewOutput` was updated. Sync `final_task_output.raw` from the post-hook payload before emit, matching `FlowFinishedEvent`. * style: drop OUTPUT sync comment and rename crew output test	2026-07-16 14:37:56 -04:00
Vinicius Brasil	79da292d79	feat: bump versions to 1.15.3a1 (#6566)	2026-07-16 13:56:31 -03:00
Vinicius Brasil	999bee8344	Add organization ID param to PlusAPI client (#6561) ... This commit adds the organization ID parameter to the PlusAPI client, in addition to the settings file. This allows for settings the organization programmatically.	2026-07-16 12:12:29 -03:00
Vinicius Brasil	985cf52028	Fix null repository agent attributes (#6560) ... Repository responses can include null optional fields such as `reasoning`. Treat them as omitted so Agent defaults apply instead of failing validation.	2026-07-16 10:13:45 -03:00
Lucas Gomide	0e5d0ecfb9	feat: add step interception points and rework execution hooks docs around @on (#6518) ... * feat: add pre_step and post_step interception points on task execution Introduces `StepContext` and the two step points in the dispatcher, and wires them around agent execution in `task.py` (sync and async paths): `pre_step` fires after `TaskStartedEvent` with the task context as payload, `post_step` fires before `TaskCompletedEvent` with the `TaskOutput`, and hook replacements are rebound in both directions. * feat: wire pre_step and post_step on flow method execution Dispatches the step points around each flow method with kind="flow_method": `pre_step` receives the dumped call params and maps returned edits back onto args/kwargs, `post_step` can rewrite the method result before it is recorded. Conformance tests cover per-method firing and output rewriting. * docs: rework execution hooks page around the @on api Replaces the standalone interception hooks catalog with a single `execution-hooks.mdx` page that teaches `@on` as the primary way to write hooks, covering the full ten-point catalog across task, flow, and LLM execution. The legacy per-point decorators stay documented in a closing section, and the `docs.json` navigation drops the removed page.	2026-07-14 14:47:18 -04:00
Lucas Gomide	a194f3867a	feat: wire execution-boundary interception points (#6517) ... * feat: wire execution-boundary interception points Adds the typed interception contexts (`crewai/hooks/contexts.py`) and wires the `execution_start`, `input`, `output`, and `execution_end` points for both crews and flows through the dispatcher. `prepare_kickoff` and `Flow.kickoff_async` fire `execution_start`/`input` so a hook can rewrite resolved inputs before the run, while `Crew._create_crew_output` and the flow tail fire `output`/`execution_end` so the final result can be observed or replaced. Closes the eight critical-path points without touching the legacy hooks. * fix: correct execution-boundary hook ordering and input aliasing Reworks the crew and flow boundary seams flagged in review. `OUTPUT` and `EXECUTION_END` now run before the completion event (`CrewKickoffCompletedEvent` and `FlowFinishedEvent`) so a `HookAborted` no longer leaves a spurious completed signal and a returned payload replacement is honored on the emitted and returned result. Boundary contexts alias `inputs` to the same object as `payload` instead of a fresh dict from `or`, so in-place edits survive read-back. Flows re-publish the resolved inputs into `flow_inputs` baggage after the `INPUT` hook so trigger-payload injection observes hook rewrites, and a resumed flow now dispatches `OUTPUT`/`EXECUTION_END` on its completion path. * chore: drop redundant seam comments from execution-boundary wiring Removes two inline comments narrating the OUTPUT/EXECUTION_END dispatch ordering in `crew.py` and the flow runtime, plus a stray sentence about enterprise adapters in the conformance-suite docstring. Comment-only cleanup, no behavior change. * fix: keep crew output typed across boundary hook dispatch `_create_crew_output` reassigned `crew_output` from the hook contexts' `payload`, which is typed `Any`, so mypy flagged `no-any-return` at the function's return. Cast the payload back to `CrewOutput` after each dispatch and split the `ExecutionEndContext` construction to satisfy `ruff format`'s line-length limit.	2026-07-14 10:43:18 -04:00
Lucas Gomide	7d21283630	feat: add generic interception-hook dispatcher (#6516) ... * feat: add generic interception-hook dispatcher Introduces `crewai/hooks/dispatch.py` as a single engine behind every interception point: a hook receives a typed context, may mutate or replace its `payload`, or raise `HookAborted(reason, source)` to stop the operation. The full `InterceptionPoint` catalog is frozen from day zero, with global and contextvar-scoped registries, an `@on` decorator, a no-op fast path, and a `HookDispatchedEvent` for telemetry. The four existing `before/after_llm_call` and `before/after_tool_call` hooks become adapters over the dispatcher, so the legacy dialect and `return False` semantics keep working unchanged while gaining the new contract. * fix: harden interception dispatcher against review findings Corrects several dispatcher edge cases surfaced in review. `_default_reducer` now reports a modification only when a `payload` is actually applied, the `agents=` filter falls back to `agent_role` for contexts without an `agent` object, and `unregister` resolves the filter wrapper stashed by `on` so a filtered hook can be removed. The tool-hook runners honor the executing agent's `verbose` flag instead of silently swallowing hook errors, and the ReAct tool path now runs `POST_TOOL_CALL` on blocked calls to match the native paths. Also adds abort-telemetry coverage and replaces the flaky absolute no-op timing budget with a relative one. * fix: honor scoped hooks on direct llm calls and register @on crew methods Direct agent-less LLM calls short-circuited on the empty global hook list, so hooks registered only for the current `scoped_hooks()` context never ran; the direct-call helpers now defer to `dispatch`, which resolves scoped hooks behind its own no-op fast path. `CrewBase` likewise only scanned the legacy `is_*_hook` markers, so `@on(InterceptionPoint.X)` methods were silently dropped — it now registers them on the dispatcher with filters applied and `self` bound. Also tightens result typing across the tool-call seams so `mypy` stays green. * refactor: scope InterceptionPoint to the points this layer wires The dispatcher only fires the model- and tool-call boundaries, so `InterceptionPoint` now lists just those four rather than the full future catalog. New points are introduced alongside the seams that dispatch them, keeping every layer free of enum members with no live consumer. The dispatcher unit tests that borrowed unused points as generic examples are remapped onto the four kept points. * test: pin per-hook fail-open at the LLM and tool seams The dispatcher swallows a hook's exception per hook rather than around the whole loop, so one buggy hook no longer silently skips every hook registered after it. These seam-level tests pin that behavior through `_setup_before_llm_call_hooks` and `run_before/after_tool_call_hooks`, and confirm an intentional `return False` block still short-circuits later hooks. * fix: run execution-scoped hooks on the agent executor model seams `_setup_before/after_llm_call_hooks` only ran the executor's snapshot hook lists, so hooks registered via `scoped_hooks()` never fired on `PRE/POST_MODEL_CALL` during normal agent execution, while the tool seams (which go through `dispatch`) merged them. The seams now append the current scope's hooks after the snapshot via `get_scoped_hooks`, matching dispatch's global-then-scoped ordering, and a scoped-only registration no longer short-circuits the seam.	2026-07-14 10:27:34 -04:00
Lucas Gomide	6452608724	fix: after_llm_call hooks no longer break native tool execution (#6531) ... * fix: don't clobber native tool-call responses in after-LLM hooks Registering any `after_llm_call` hook broke native tool execution: the executor invokes `_setup_after_llm_call_hooks` on the intermediate response that carries the model's tool calls, the non-str payload was stringified for the response-rewrite pass, and the executor then treated that string as a final answer instead of executing the tools. Structured payloads (neither `str` nor `BaseModel`) now pass through untouched, mirroring the isinstance guard `_invoke_after_llm_call_hooks` already applies on the direct-call path; hooks still fire on the follow-up textual response. Fixes #6529 * style: shorten the tool-call guard comment	2026-07-14 09:49:21 -04:00
Vinicius Brasil	9d72e269e4	Remove redundant CEL text helper (#6528) ... This commit removes the redundant CEL text helper, in favor of the easier interpolation syntax.	2026-07-13 14:29:36 -04:00
João Moura	fb8e93be25	fix(flow): don't double-append the turn reply when a handler trims history (#6510) ... handle_turn() (and stream_turn) decided "did the handler append its reply?" by snapshotting the assistant-message count before kickoff and appending the stringified result when the count came back unchanged. A handler that appends its reply and then trims state.messages to a cap — a normal bounded-context pattern — left the count unchanged, so the fallback appended the reply a second time on every turn once trimming engaged, and the duplicates then crowded real turns out of the capped window. Replace the count heuristic with an explicit per-turn flag: append_assistant_message() sets _assistant_reply_appended, handle_turn and stream_turn clear it before kickoff and only fall back when no assistant message was appended during the turn. The now-unused _assistant_message_count() helper is removed. Fixes EPD-181. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 20:01:07 -07:00
João Moura	4fdb7f2bfb	fix(tools)!: make tool-result caching opt-in instead of on by default (#6509) ... * fix(tools)!: make tool-result caching opt-in instead of on by default Tool-result caching defaulted to on (Crew.cache=True, and standalone agents self-wired a CacheHandler at construction), so an LLM calling the same tool with identical arguments twice in one run silently got the first result back without the tool executing. For live-data tools that is a confidently stale answer; for state-mutating tools the second action is silently dropped. Caching is now opt-in with the machinery unchanged: - Crew.cache defaults to False; Crew(cache=True) restores today's behavior exactly (agents still default to participating when a crew offers its handler, and Agent(cache=False) still opts an agent out). - Standalone agents no longer self-wire a cache; Agent(cache=True) or an explicit cache_handler opts in. Previously even Crew(cache=False) agents cached via this self-wired handler. - Per-tool cache_function write gating is unchanged once opted in. Existing tests that exercised the caching machinery now opt in explicitly; new regression tests cover the default (both identical calls execute), crew-level opt-in dedup, and agent-level wiring. Fixes EPD-180. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): don't let copy() turn the cache default into an explicit opt-in Agent.copy() rebuilds from model_dump(), which includes the field default cache=True, so the copy's model_fields_set contained "cache" and _setup_agent_executor wired a CacheHandler the source agent never opted into (Bugbot review finding). Drop "cache" from the dump when it was not explicitly set on the source; explicit opt-ins still survive copying. Also sync the Crew and BaseAgent class docstrings with the new opt-in cache semantics (CodeRabbit review findings). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): preserve cache_handler-only opt-in across Agent.copy() copy() excludes cache_handler from the rebuilt agent, so an agent that opted into tool-result caching solely via an explicit cache_handler lost caching after copy() (Bugbot review finding). Carry the consent as cache=True on the copy when the source has a handler wired and hasn't explicitly disabled caching — the copy wires its own fresh handler, matching pre-change copy semantics (copies never shared the source's handler instance). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(crew): offer the crew cache handler to the hierarchical manager The hierarchical manager agent is created in _create_manager_agent, outside the validation-time agents loop that offers the crew's cache handler — and managers no longer self-wire a handler — so Crew(cache=True) hierarchical runs never cached the manager's delegation tool calls (Bugbot review finding). Offer the shared crew handler when the crew opted in; a user-provided manager with cache=False stays excluded via the existing set_cache_handler gate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(agent): only construction-time cache opt-ins survive Agent.copy() The previous copy() fix treated any wired cache_handler as consent, but agents that merely received the crew's shared handler at kickoff (set_cache_handler from Crew(cache=True)) never opted in themselves — their copies must not become standalone cachers (Bugbot review finding). Record the opt-in signal in _setup_agent_executor, which runs at construction before any crew wiring can happen, and have copy() consult that flag instead of inspecting cache_handler after the fact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 17:37:36 -07:00
João Moura	bfa652a7be	fix(tools): stop rewriting the authored tool description at construction (#6508) ... * fix(tools): stop rewriting the authored tool description at construction BaseTool.model_post_init silently replaced the public description field with the LLM-facing composite ("Tool Name: ...\nTool Arguments: ...\n Tool Description: <authored>"), breaking equality assertions on authored text and hiding the extra prompt tokens from token-careful authors. The authored description now survives construction as written. The composite is composed on demand via a new formatted_description property on BaseTool and CrewStructuredTool (shared format_description_for_llm helper), and every prompt path that relied on the baked-in composite — render_text_description_and_args, ToolUsage._render, and tool-usage error messages — now renders through it, so the text the LLM sees is unchanged. The helper strips any pre-existing composite block before composing, so tools deserialized from old checkpoints and adapters that still bake the composite into the field (e.g. the crewai-tools MCP adapter) don't get double-wrapped. BaseTool._generate_description remains as a no-op hook because subclasses override it and model_post_init still calls it. Fixes EPD-179. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(tools): harden composite-description handling after review - Anchor the pre-baked-composite check to the actual three-line block shape instead of a naive substring match, so authored prose that merely mentions "Tool Description:" is never truncated (CodeRabbit / Bugbot review finding). Shared as strip_composite_description_prefix() and reused by the function- calling schema builder, which had the same naive split. - Make render_text_description_and_args tolerate duck-typed tools without a real formatted_description string (fixes CI: step-executor tests pass Mock tools whose auto-created attribute is not a str). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-07-10 20:33:57 -03:00
João Moura	b65c8487d2	fix(output): expose token usage under both names on agent and crew results (#6507) ... Agent.kickoff() returned LiteAgentOutput with a plain dict at .usage_metrics and no token_usage attribute, while Crew.kickoff() returned CrewOutput with a UsageMetrics object at .token_usage and no usage_metrics attribute — so a usage accessor written for one path raised AttributeError on the other, and every consumer had to duck-type both shapes. Give both result types both surfaces, each name with one consistent shape everywhere: .token_usage is a UsageMetrics object and .usage_metrics is a plain dict, on both LiteAgentOutput and CrewOutput. Added as read-only properties, so existing fields, serialization, and constructors are unchanged. Fixes EPD-178. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 20:29:34 -03:00
João Moura	a8b3ecb723	fix(agent): report per-call usage metrics on kickoff results (#6506) ... * fix(agent): report per-call usage metrics on kickoff results Agent.kickoff() populated result.usage_metrics from the LLM instance's lifetime token accumulator, so counts grew across calls and pooled across agents sharing one LLM object — a second agent's first turn appeared to cost the whole preceding session. Snapshot the accumulator when a kickoff starts and report the delta on the result (guardrail retries included), via the new UsageMetrics.delta_since(). The LLM instance's cumulative counters are untouched: get_token_usage_summary() keeps lifetime totals for crew-level aggregation, and its docstring now states that scope explicitly. Applies to both Agent and the deprecated LiteAgent, sync and async paths. Fixes EPD-177. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(agent): drop lite_agent.py diff, add guardrail-retry usage test Per review: LiteAgent's kickoff path is no longer used, so the per-call usage snapshot only needs to live in agent/core.py — revert the lite_agent.py changes entirely. This also removes the duplicated _current_usage_summary helper and the instance-attr baseline CodeRabbit flagged. Add the requested guardrail-retry regression test: a guardrail that rejects the first attempt and accepts the second must yield usage_metrics covering both attempts (2x a single-attempt kickoff). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 14:17:45 -07:00
João Moura	7967b19057	fix(flow): stop replaying previous turn's intent when route_turn() returns falsy (#6505) ... In conversational flows, a falsy return from an overridden route_turn() fell back to the sticky state.last_intent from a previous turn, silently re-running the prior turn's handler for an unhandled input. The fallback exists for the legacy default_intents path, where receive_user_message() classifies the intent fresh each turn. Track that per-turn classification in _turn_classified_intent (cleared on every turn reset) and route on it instead, so a falsy route_turn() now falls through to the built-in answer_from_history/converse defaults and never reuses stale routing state. Fixes EPD-176. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-07-10 11:44:57 -07:00
João Moura	85c467dfe2	feat(cli): run declarative flows on the TUI (headless terminal fallback) (#6484) ... * feat(cli): run declarative flows on the TUI with a headless terminal fallback Declarative flows now run on the CrewRunApp TUI when interactive, matching declarative crews and conversational flows. Headless contexts — CREWAI_DMN (deploy), piped output, CI, any non-TTY — fall back to the direct-terminal kickoff, gated by is_interactive() (folds in the CREWAI_DMN check and requires a real TTY). The TUI shows per-method progress: a new STEPS panel driven by flow method events (FlowStarted / MethodExecutionStarted/Finished/Failed), each labeled with its declarative call type (crew/agent/expression/…) read from the flow definition. Crews/agents inside a method keep streaming in the main panel via the existing crew/task/LLM handlers. - crew_run_tui.py: _run_flow_worker (flow.kickoff in a thread worker; reuses _on_crew_done/_on_crew_failed + _stringify_output), _is_flow_run gate so crew rendering is byte-identical, flow-event subscriptions building _flow_steps, and the STEPS sidebar + flow-aware header. - run_declarative_flow.py: is_interactive() branch → _run_declarative_flow_tui (EventListener, method-type map from flow._definition, crew-parity exit codes and deploy chaining) or the existing terminal path. Deviation from the approved plan: gate on is_interactive() rather than is_dmn_mode_enabled() alone, so non-TTY runs (CI/pipes/CliRunner) never launch a TUI — this also keeps existing headless flow tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * fix(cli): force flow events on for the TUI so STEPS renders under suppress_flow_events Review follow-up: the STEPS panel and header are driven by flow method events (FlowStarted / MethodExecution*), but the declarative runtime skips emitting those when the flow declared config.suppress_flow_events. Interactive TUI runs would then keep STEPS on "waiting…" and the header on "Starting flow…" while nested crews still execute. _run_declarative_flow_tui now forces flow.suppress_flow_events = False for the interactive run (mirroring how the conversational path mutates the flow for the TUI). The headless/terminal path never reaches this and keeps the flow's declared setting. Regression test: test_run_declarative_flow_tui_enables_flow_events. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * fix(cli): clear flow header's current method when a method ends Review follow-up: the flow header keys off _current_method, which was set on MethodExecutionStarted but never cleared on Finished/Failed. Between steps (or after a failed method before kickoff exits) the header kept spinning the old method name while the STEPS sidebar already showed it done/failed. _clear_current_method now drops the header's active method when it ends, falling back to another still-active step (methods can overlap) or none. The header's idle fallback shows "Working…" once a step has run and "Starting flow…" only before the first method. Tests: test_current_method_clears_and_falls_back_across_overlap, plus a _current_method assertion in test_flow_method_events_build_steps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * fix: suppress flow console panels in TUI mode; clear header agent on method change Two review follow-ups: 1) Method panels break Textual TUI (Cursor): forcing suppress_flow_events off so the STEPS panel receives events also un-gated the EventListener's Rich flow/method panels (ConsoleFormatter.print_panel prints is_flow=True panels regardless of verbose), which interleave with Textual and corrupt the TUI. print_panel now skips is_flow panels when is_tui_mode() is set (the same context the TUI worker already establishes and the tracing listeners already honor). Non-TUI/headless flow runs are unaffected. Test: test_console_formatter_tui_mode. 2) Flow header showed a stale agent (CodeRabbit): _current_agent persisted across methods. It's now cleared when a method starts and when the active method changes, so the header never shows the previous method's agent until a new agent event arrives. Test: test_flow_method_transitions_clear_current_agent. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * fix(cli): keep flow name over nested crews; show paused flow methods Two review follow-ups on the flow TUI: 1) Crew kickoff renamed the flow (Cursor): CrewKickoffStartedEvent overwrote _crew_name / the app title with a nested `call: crew` step's crew name, so the post-run summary could be labeled with a child crew. The rename is now gated on `not _is_flow_run`, preserving the flow's name; crew runs still adopt the crew name. Tests: test_crew_kickoff_does_not_rename_flow_run, test_crew_kickoff_renames_in_crew_mode. 2) Paused methods showed active (Cursor): the TUI didn't handle MethodExecutionPausedEvent, so a @human_feedback pause left the STEPS spinner running (flow status panels are suppressed in TUI mode). It now marks the step "paused" (⏸, teal) and the header shows "waiting for feedback" instead of a spinner. Test: test_method_paused_marks_step_paused. Note: interactively *providing* human feedback from the flow TUI is a separate follow-up; this only makes the pause visible instead of a silent stuck spinner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * fix(cli): run human-feedback declarative flows on the terminal, not the TUI Two review follow-ups, both rooted in @human_feedback methods: - Paused flow marked complete (Cursor): async human feedback makes kickoff RETURN a HumanFeedbackPending marker (not raise), which _run_flow_worker would stringify and report as a successful completion with exit 0. - Sync feedback breaks TUI (Cursor): default (sync) @human_feedback collects input via the flow runtime's Rich console.print + blocking input(), which interleaves with Textual and leaves the user unable to review output or submit feedback. run_declarative_flow now routes any flow whose declarative definition declares human feedback (_flow_uses_human_feedback) to the terminal path, where blocking input and Rich prompts work natively — regardless of interactivity. Non-feedback flows still get the TUI. Tests: test_flow_uses_human_feedback_detection, test_human_feedback_flow_uses_terminal_even_when_interactive. Fully interactive human feedback inside the TUI remains a separate follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh * refactor(cli): address review — Flow typing, debug logging, flow-vs-crew naming Review follow-ups from @lucasgomide: - Type flow helpers as Flow[Any] (via TYPE_CHECKING import) instead of Any and drop the defensive getattr chains — _definition is a typed PrivateAttr and name/suppress_flow_events are typed fields, so attribute access is safe. - Replace the silent `except Exception: pass` blocks with logger.debug(..., exc_info=True) so unexpected failures are diagnosable in the field (_flow_method_types, _flow_uses_human_feedback, suppress_flow_events toggle). - Flow-vs-crew naming: the flow worker now uses group="flow" (was the misleading "crew"), and the shared completion/failure handlers report the run with an entity-aware noun ("flow" vs "crew") via _run_noun. Deferred (separate PR): the os._exit(130) hard-kill on user quit is kept as-is to match the existing crew convention (run_crew._run_json_crew). Tests: test_flow_done_uses_flow_wording_for_unfinished_tool; existing crew wording tests unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RBYGqJHC2TMC6fonFziuuh --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 11:42:12 -03:00
Lorenze Jay	7baf8f9ba1	improving custom OpenAI urls (#6490) ... * Support legacy OpenAI base URL env var * Add custom OpenAI-compatible endpoint support * Refactor OpenAI completion module test to restore original module state - Added logic to save and restore the original OpenAI completion module during the test to prevent issues with class re-imports affecting subsequent tests. - Ensured that the test checks for the presence of the module and its attributes only after the module is properly reloaded. - Improved test reliability by avoiding potential failures due to module state changes across tests. * addressing comments	2026-07-09 15:30:16 -07:00
Lucas Gomide	860817cbcd	Drain memory writes before kickoff and flow completion events (#6497) ... * fix: drain memory writes before kickoff and flow completion events Background memory saves from the final task could still be in flight when `CrewKickoffCompletedEvent`/`FlowFinishedEvent` fired, so telemetry listeners tore down before `MemorySaveCompletedEvent` arrived and the save span surfaced as "Span orphaned" errors in traces despite the record persisting. `Crew` now drains all pending saves — including per-agent `agent.memory` pools, which the old `finally`-only drain missed entirely — before emitting the completion event, with the same ordering applied to both `FlowFinishedEvent` emit paths in the flow runtime. * fix: address review findings on the memory drain paths Bugbot and CodeRabbit flagged gaps in the drain coverage: the hierarchical `manager_agent` memory pool was never drained, `Crew.akickoff` lacked the exception-path safety net that sync `kickoff` has, and `finalize_session_traces` emitted the deferred session-end `FlowFinishedEvent` without draining first. Also offloads the pre-emit drains in the flow runtime to `asyncio.to_thread` so the blocking wait doesn't stall other coroutines sharing the event loop. * fix: flush event bus after memory drain in flow completion paths Bugbot flagged that flow paths went straight from the memory drain to `FlowFinishedEvent`, while crew kickoff flushes the bus in between. Save completion events emitted during the drain could still have pending async handlers when flow-finished triggered trace teardown. Adds a `crewai_event_bus.flush()` after the drain at both flow runtime emit sites and in `finalize_session_traces`, mirroring `Crew._create_crew_output`.	2026-07-09 15:01:14 -04:00
Lorenze Jay	589baa3e7f	feat: bump versions to 1.15.2 (#6477)	2026-07-07 18:59:59 -07:00