2939 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Sathyajith MCandVidit Ostwal	b90fa6e822	fix(cli): show actual task output in log-tasks-outputs (#7936) ... * fix(cli): show actual task output in log-tasks-outputs * fix(cli): show task result instead of storage blob in log-tasks-outputs --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-10-08 05:22:13 +00:00
Lorenze Jay	1d4015439a	[docs-freeze] docs: snapshot and changelog for v1.15.25 (#7946) 1.15.25	2026-10-07 18:51:56 -05:00
Lorenze Jay	7ed27d764a	feat: bump versions to 1.15.25 (#7945)	2026-10-07 18:48:27 -05:00
Lorenze Jay	d5efc45847	[docs-freeze] docs: snapshot and changelog for v1.15.24 (#7942) 1.15.24	2026-10-07 10:39:31 -07:00
Lorenze Jayandgithub-actions[bot]	82d09de711	feat: bump versions to 1.15.24 (#7941) ... * feat: bump versions to 1.15.24 * chore: update tool specifications --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-10-07 17:35:48 +00:00
João MouraandClaude Opus 5.5	00e2ff98e9	feat(cli): crewai eval prints a markdown brief when run by an agent (#7907) ... * feat(cli): crewai eval prints a markdown brief when run by an agent When stdout is not a terminal (or CREWAI_DMN is on), `crewai eval` and `crewai eval --models` print the poll response's `brief_markdown` after the verdict and the report link — written straight to stdout, never through Rich markup — or "Brief (markdown): <brief_url>" when only the link came. An older AMP sends neither and nothing extra is printed. In a terminal nothing changes. Exit codes unchanged. `crewai eval --help` and the `--models` help say so, and the AGENTS.md the crew, flow and declarative-flow templates scaffold gains an "Evaluating" section telling a coding agent to run `crewai eval` after a change and act on the brief. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs(cli): an agent re-runs before it re-evaluates; each command's exit rule; the brief may be a link Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(cli): keep the eval guidance out of tool projects; the brief is conditional in --help `crewai create tool` copies the shared AGENTS.md too, but a tool project has no `crewai run` and no traced run for `crewai eval`. The evaluation blocks are marked in the template and dropped for a tool (`evaluation=False`); crew, flow and JSON-crew projects keep them, markers stripped. --help now says the brief prints when AMP provides it, else its link, else nothing more. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-07 10:28:34 -07:00
Lorenze Jay	c6bf5ef5d4	feat(flow): queue relevant background replies (OSS-192) (#7911) ... * feat(flow): queue relevant background replies (OSS-192) * fix(flow): fence queued output after shared reply interruption * fix(flow): keep prepared delivery retries side effect free	2026-10-07 09:18:05 -07:00
Lorenze JayandVidit Ostwal	19d4154b0b	feat(flow): add experimental turn and reply identities (OSS-197) (#7909) ... * feat(flow): introduce experimental turn and public reply identities This update adds a new module for handling public replies within an existing conversational flow. It introduces the `TurnRunner`, which manages the lifecycle of turns and replies, allowing for experimental features such as tracking input revisions and reply identities. The changes include new classes for `TurnRecord`, `ReplyRecord`, and `TurnState`, enhancing the flow's capabilities while maintaining backward compatibility with existing APIs. Additionally, tests have been added to ensure the functionality of the new features. * fix docs * fix(flow): preserve live turn state and terminal events * fix(flow): remove redundant failure terminal marker --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-10-07 13:56:34 +05:30
Elif Sema BalciogluandVidit Ostwal	68f82f936d	Add Oracle Integrations (#6026) ... * Add Oracle Integrations * Update uv.lock * Fix bugs * Fix bugs * fix: resolve Oracle vector search review findings * fix: ensure Oracle test cleanup and satisfy lint checks * fix: correct Oracle filters limits and batch rollback * fix: address Oracle embedding and vector search review findings * fix: validate Oracle filters and environment configuration --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-10-07 11:58:18 +05:30
Sathyajith MCandVidit Ostwal	e836a191cf	fix(cli): correct train filename error message (#7903) ... * fix(cli): correct train filename error message * fix(cli): fail train on invalid input with nonzero exit --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-10-06 18:46:20 +00:00
Gabe Milani	19dd81148c	fix(flow): let a start step re-run on the events it listens to (#7922)	2026-10-06 18:34:31 +00:00
Vidit Ostwal	8225e322e5	fix(deps): clear docling, fsspec, multidict, pymongo, and snowflake advisories (#7916) ... The lock was still on versions flagged by GHSA-q43m-vhcp-mhvm, GHSA-27vj-qcqg-25rc, GHSA-54p9-h82j-f925, the pymongo 4.18.2 fixes, and GHSA-qqj6-54q6-cxv6.	2026-10-06 09:32:22 -07:00
Vidit Ostwal	1133f16cab	fix(deps): bump oauthlib to 4.0.0 to clear PYSEC-2026-4114 (#7906)	2026-10-05 11:45:05 -07:00
Lorenze Jay	738c8e19e3	feat(flow): add experimental job lifecycle and runner (#7864)	2026-10-02 17:03:54 -07:00
Gabe Milani	8078f9130c	fix(flow): let human_feedback emit steps expose the review in outputs (#7850)	2026-10-01 17:31:55 +00:00
Vidit Ostwal	19713955dd	fix(deps): bump pypdf to 6.19.0 to clear pip-audit findings (#7851) ... pypdf 6.16.2 is flagged for eight advisories, all fixed in 6.19.0.	2026-10-01 17:25:38 +00:00
João MouraandClaude Opus 5.5	fbcf2de39d	fix(tracing): keep tool and task outputs whole in exported spans (#7833) ... * fix(tracing): keep tool and task outputs whole in exported spans Every gen_ai.* content attribute was capped at 32 KiB, and a value over the cap that was not a message array became an envelope holding a 4 KiB preview: a 33 KB tool result reached the trace as 4 KB. Graders checking a summary against the data a tool returned could not decide. - DEFAULT_MAX_ATTR_BYTES is 384 KiB, sized to Wharf's 3,072,000-byte request limit: seven attributes at the bound still fit one request. - Over the bound, a value loses only what is over it (the envelope preview fills the bound; a message's text is cut by the overshoot, not halved), with the existing <attr>.truncated / <attr>.original_size_bytes markers. - Every other string attribute (crewai.task.output, crewai.mcp.tool_result, serialized flow state) gets the same bound and markers; before, one huge value made the span too large for Wharf and the exporter dropped it whole. - An OpenTelemetry SDK attribute length limit, when set, lowers the bound, so the SDK (which cuts without a marker) never has anything left to cut. CREWAI_OTEL_MAX_ATTR_BYTES still replaces the bound; no new setting. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(tracing): honour SDK length limits as the SDK reads them; cut plain attributes plainly - The span attribute length limit is read like SpanLimits: the span setting wins over the general one, an explicitly empty value means unlimited, and 0 is a limit (every string cut to nothing, with crewAI's marker). - Plain attributes (crewai.task.output, crewai.mcp.tool_result, flow state) keep their head up to the bound with the .truncated / .original_size_bytes markers; only gen_ai.* messages get message-aware truncation, so a role-bearing JSON list a task produced is never reshaped as a conversation. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(tracing): clamp the attribute bound at the Wharf-safe ceiling; shrink a span that does not fit instead of dropping it - CREWAI_OTEL_MAX_ATTR_BYTES and the OTel SDK span attribute length limit can lower the 384 KiB bound, never raise it. A higher CREWAI_OTEL_MAX_ATTR_BYTES is clamped with one warning naming the value, the ceiling and why (Wharf's 3,072,000-byte request). No new setting. - GrantSpanExporter no longer drops a span whose attributes, each within its bound, add up to more than one request: the largest string attributes are cut by the overshoot, each with .truncated / .original_size_bytes, until it fits. A span whose excess is in its resource, scope or events is still skipped, as before. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-01 03:37:42 -03:00
3 people	ca1d55abb3	fix(tracing): a refused trace grant runs the crew untraced instead of failing it (#7812) ... * fix(tracing): a refused trace grant runs the crew untraced instead of failing it An authenticated run asks AMP for a trace grant as it starts, and a refusal raised out of `begin_execution` — so when a `crewai login` expired or a token was revoked, every traced crew and flow failed with "AMP trace grant request failed (HTTP 401)" before it did any work. A trace is a record of the run, not a condition of it. Now the run goes on untraced and logs one warning naming the fix: for a 401/403, "Run `crewai login` again to trace your runs"; otherwise that the run itself is unaffected. It never falls back to an anonymous upload of a logged-in user's run (the grant client's "never downgrade a supplied credential" still holds). The test that pinned the raise now pins the run completing, the context restored, nothing uploaded, and the warning. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(tracing): name the credential AMP refused, not always the saved login `tracing_credential()` sends CREWAI_USER_PAT first, then the platform integration token, then the saved `crewai login` — so "run `crewai login` again" was the wrong fix for two of the three, and sent somebody to refresh a credential that was never the problem. `tracing_credential_source()` follows the same order (one private resolver behind both), and the warning names the credential that was refused and the fix for that one. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(tracing): a blank credential runs the crew untraced too The grant client refuses a blank credential in its constructor with the same TraceGrantError a refused grant raises, and the constructor sat outside the boundary — so that case still failed the run. It is inside now. The new tests also import the grants module one way only. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(tracing): the refused credential is the one that was sent Resolve the tracing credential and its source once, as a pair, and use that pair for both the grant request and the warning. Reading the source again after the request could name a credential AMP never saw. Also assert a refused grant never builds a span exporter. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(deps): bump pyjwt to >=2.14.0 and defer oauthlib 4.0.0 PyJWT 2.14.0 fixes GHSA-w6j9-cwv2-h6wq and several other advisories in PyJWKClient and JWK parsing, which crewai-core uses to verify CLI login tokens. Raise the floor in crewai, crewai-cli and crewai-core so installs cannot resolve a vulnerable release, and lock 2.14.0 (2.15.0 rejects padded tokens until 2.15.1, which is still inside the uv cooldown). oauthlib 4.0.0, the fix for GHSA-xpv3-w29h-x7cv, is under two days old and inside the 3-day exclude-newer cooldown. The flaw is in the server-side PKCE verifier check; oauthlib reaches CrewAI only as an OAuth client (chromadb -> kubernetes -> requests-oauthlib). Ignore the advisory in pip-audit until 4.0.0 clears the cooldown, with a dated TODO. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(deps): bump pyjwt to 2.15.0, urllib3 to 2.8.0 and virtualenv to 21.13.0 Advisories published 2026-09-30 against the versions #7823 locks: - PyJWT 2.14.0: GHSA-42vr-xj54-vc7v (fixed in 2.15.0); floor raised to >=2.15.0 in crewai, crewai-core and crewai-cli - urllib3 2.7.0: GHSA-8988-9cw3-xx77, GHSA-gh4c-6fx4-qh6g, GHSA-vxq7-64xx-v4gw (fixed in 2.8.0); override raised to >=2.8.0 - virtualenv 21.4.2: PYSEC-2026-4011..4014 (fixed by 21.7.13); override >=21.7.13, locked at 21.13.0 All three fixes are older than the 3-day exclude-newer cutoff, so no per-package override is needed. Local pip-audit over the exported lock: no known vulnerabilities (8 ignored, the repo's list). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Co-authored-by: Craig Estep <craig.estep@crewai.com>	2026-09-30 21:47:17 -07:00
João MouraandClaude Opus 5.5	b6bfae60b5	fix(deps): bump litellm to 1.88.6 for GHSA-3cv6-jpf6-8222 (#7835) ... litellm <1.88.6 has GHSA-3cv6-jpf6-8222 (CVE-2026-84377): authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters in the LiteLLM proxy server. crewAI uses litellm as a client SDK and never runs the proxy, but pip-audit flags the package and fails the vulnerability scan on every PR. - lib/crewai/pyproject.toml: crewai[litellm] floor litellm>=1.84.0 -> >=1.88.6 - pyproject.toml: advisory comment beside the other overrides - uv.lock: litellm 1.84.8 -> 1.88.6; nothing else moved (same dependency set) 1.88.6 (2026-08-09) is older than the 3-day exclude-newer cutoff, so no exclude-newer-package override is needed. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-01 01:34:20 -03:00
dependabot[bot]	fad444da95	chore(deps): bump the security-updates group across 1 directory with 2 updates (#7832) ... Bumps the security-updates group with 2 updates in the / directory: [chromadb](https://github.com/chroma-core/chroma) and [accelerate](https://github.com/huggingface/accelerate). Updates `chromadb` from 1.1.1 to 1.5.9 - [Release notes](https://github.com/chroma-core/chroma/releases) - [Changelog](https://github.com/chroma-core/chroma/blob/main/RELEASE_PROCESS.md) - [Commits](https://github.com/chroma-core/chroma/compare/1.1.1...1.5.9) Updates `accelerate` from 1.13.0 to 1.15.0 - [Release notes](https://github.com/huggingface/accelerate/releases) - [Commits](https://github.com/huggingface/accelerate/compare/v1.13.0...v1.15.0) --- updated-dependencies: - dependency-name: chromadb dependency-version: 1.5.9 dependency-type: direct:production dependency-group: security-updates - dependency-name: accelerate dependency-version: 1.15.0 dependency-type: indirect dependency-group: security-updates ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-10-01 00:17:03 -03:00
João MouraandClaude Opus 5.5	1b9bbccbed	feat(cli): crewai eval --models, and llm_overlay swaps models as well as roles (#7811) ... * feat(llm): llm_overlay maps models too, not only agent roles A key `model:<provider/model>` maps every LLM built from that model string inside the block, and `model:*` every LLM built from any model string. That reaches what a role cannot: a flow step's own `LLM(...).call()`. The key is read in `LLM.__new__` (and so `create_llm` and an agent's `llm="..."`), and on an agent's declared llm built outside the block; a role key still wins for that agent. The caller's settings follow the mapped model by the rule a declared llm's do. `MODEL_KEY_PREFIX` is public so another package can feature-detect the form. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * feat(telemetry): allow-list cli_usage:eval_models attributes The span `crewai eval --models` records carries whether the caller was logged in, the models compared (provider/model names) and how many, in both telemetry classes. Nothing about the run, its output or the organization. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * feat(cli): crewai eval --models compares models on the deployment `crewai eval --models "a,b"` (and `--deployment UUID` when AMP cannot tell the deployment from the project id) asks AMP for a models evaluation: the project id, the models from one comma-separated list (stripped, repeats dropped, provider/model required, 1-5) and the project's eval.jsonc. It needs the login, prints and opens the report link, says where the comparison is while it runs, then prints one row per model (goal, tasks, agents, tools, cost, time; the deployed one marked, the best per column starred) and the top three suggestions. Exit 0 when it finished, 1 when it failed or could not start. Everything from the wire is printed as Text. The comparison is counted as `cli_usage:eval_models` once AMP accepts it. Mode 1 now sends the project id with `create_evaluation` too, so every evaluation is filed under the project it is about. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * feat(cli): crewai deploy create and push send the project id Every create (git or ZIP) and every push (redeploy by name or uuid, or a ZIP update) carries `[tool.crewai].project_id` when the project has one, so AMP knows which project a deployment runs and `crewai eval --models` can find it. The id is read, never minted: a deploy does not rewrite pyproject.toml. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(llm): a model key maps an LLM whose declared SDK is not installed Nothing is built on the declared model, so a missing SDK for it is no reason to fail the mapped build; its credentials cannot be matched to the new provider, so none are carried. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * feat(cli): crewai eval --models leaves its criteria behind as eval.jsonc When the comparison's answer carries `eval_config` and the project has no eval.jsonc, it is written through `write_eval_config` and the same one line Mode 1 prints says so. An existing file is never overwritten. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(llm): a model key compares providers by provider, not by class `_same_route_provider` now follows `_same_provider`'s rule case for case: a LiteLLM-routed `LLM(...)` is on the same provider as a native route when its provider names that native class, so its key and endpoint follow a model key to another model of the same provider. Another provider still gets none. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * chore(llm): say why mark_mapped may skip an object, and one import form in its tests Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(cli): usage stats name a compared model only when it is a public one `cli_usage:eval_models` carried the `--models` strings as typed, and those can identify a customer: a fine-tune id, an Azure deployment name, a self-hosted model or host. A model is now sent by name only when it is an exact entry of crewAI's model catalog (`LLM_CONTEXT_WINDOW_SIZES`), else as `<provider>/other`, and a provider crewAI does not route as `other/other`. An `ft:` id is never sent. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(cli): a refused comparison's test no longer keeps a None return Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(llms): re-importing OpenAI's completion module restores its package attribute `test_openai_completion_module_is_imported` deletes the module from sys.modules and lets `LLM(...)` import it again, which binds the new module on `crewai.llms.providers.openai` as well. monkeypatch restored only the sys.modules entry, so every later test on that worker saw two module objects for one name: `patch("crewai.llms.providers.openai.completion.X")` patched the attribute's module while `from ... import X` read sys.modules'. On Python 3.10 that made tests/llms/azure/test_azure_responses.py fail whenever it shared a worker with test_openai.py and test_crew_loader.py, which the new tests' even split now did. The attribute is restored too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(llm): model keys strip only a model's own prefix; a role builds from the declaration Two review findings on the model-for-model overlay: - `overlay_model_for_model` took the text after the first slash as another name for the model, so an aggregator's route (`openrouter/openai/gpt-4o`) matched a `model:openai/gpt-4o` or `model:gpt-4o` key meant for the native model. A prefix is now stripped only when it is a native provider's own and what remains has no slash; an instance on an aggregator is compared as `<provider>/<its model id>`. - With a role key and a model key both active, the model key mapped the declared llm first and the role's model was built like that mapped instance, losing the caller's key and endpoint. The overlay now remembers what the caller declared for every llm it built, and a role key is built from that declaration. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(llm): model keys read a provider's other names; a LiteLLM choice survives a missing SDK - The router's provider aliases are now one table, `crewai.llm.PROVIDER_ALIASES`, and `llm_overlay` compares model names through it: `google/x` and `gemini/x` are one model whether the llm is built in the block or was built before it (a prebuilt instance records `gemini`). An exact key still wins, and an aggregator's route is still compared whole. - When the declared model's SDK is missing, a caller's explicit `is_litellm=True` is kept for the mapped model instead of dropping to a native route. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(deploy): a git create sends the project id once, at the top level AMP reads project_id at the top level on every deploy route, so the git create no longer repeats it inside `deploy`. The redeploy docstring records why its optional body is safe on an AMP that predates project ids. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-30 10:53:42 -07:00
Vidit Ostwal	a0d16dde6e	refactor: move message summarization into SummarizeMessages (#7815) ... * refactor: move message summarization into SummarizeMessages Keep context compaction in one class so agent_utils only starts the summary when the context window is exceeded. * refactor: keep SummarizeMessages inside agent_utils Reuse one summarizer instance and drop the separate module now that compaction lives next to summarize_messages. * fix: retry summarizer chunks with tighter token estimates on overflow When a chunk hits the context window during summarization, re-chunk at 3 and 2.5 chars per token before failing. * refactor: drive summarizer retries with char_level_index on summarize Chunk at levels 4/3/2.5 chars per token and recurse through summarize until index 3 raises. * refactor: colocate summarizer token levels on SummarizeMessages Keep chars-per-token retry levels as a class constant instead of module scope. * test: cover summarizer retries across all char-per-token levels Assert chunking uses indices 0–2 when context overflows twice before a successful summary. * fix: use a new SummarizeMessages instance per compaction Avoid sharing one summarizer across concurrent context-window recoveries. * fix: keep summarizer context retries inside async _summarize_one Re-chunk failed chunks at tighter token levels with gather instead of calling summarize recursively. * refactor: nest _summarize_one inside _summarize_all Per-chunk summarization is only reachable from _summarize_all or its own retry path; tests exercise _summarize_all instead of calling _summarize_one directly.	2026-09-29 21:23:28 +05:30
João MouraandClaude Opus 5.5	243e819952	fix(tracing): report tracing sent usage from the grant exporter (#7810) ... Since 1.15.22 every crew and flow kickoff owns an execution uuid, so the legacy TraceBatchManager handlers never finalize a batch and the `tracing:ephemeral_sent` / `tracing:authenticated_sent` Feature Usage events stopped. Emit them from GrantSpanExporter.record_export, the point both upload tiers reach once every span has arrived. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-29 13:10:04 +05:30
Vidit Ostwal	a6e6d0f9d8	refactor(llms): centralize and refresh context windows (#7796) ... * feat(llms): centralize context window definitions * refactor(llm): use shared context window resolver * refactor(llms): share native context window lookup * test(llms): cover context window parity * fix(llms): preserve regional Bedrock context window * chore(llms): refresh provider context window catalogs * fix(llms): restore affected model context windows * fix(llms): add active Azure and Anthropic context windows Record catalog limits for current Azure OpenAI and Claude model IDs so lookups match the providers' active context windows. * fix(llms): sync Gemini and Bedrock context windows Drop retired catalog IDs and record the active Gemini and Bedrock text-model limits from the current provider docs. * fix(llms): add missing OpenAI context windows Record active OpenAI IDs that do not match an existing prefix, including gpt-5.6-cyber so it keeps its 400k window. * fix(llms): keep Gemini thinking snapshot window in sync Restore the retired thinking snapshot so native Gemini and LiteLLM resolve the same 1M context window. * test(llms): drop retired Gemini thinking snapshot from parity The model is no longer in the Gemini catalog, so native and LiteLLM no longer need to agree on its context window. * test(llms): expect Azure GPT-4 and GPT-4o to share a 128k window Azure GPT-4 is no longer smaller than GPT-4o, so the comparison asserted equal usable windows. * fix(llms): address context-window review findings Keep provider catalogs from overwriting each other, restore Gemma and legacy Bedrock Claude windows, and match the global Kimi inference id. * fix(llms): drop unused context-window re-exports from LLM Import the usage ratio from context_window in tests so llm.py no longer re-exports unused constants.	2026-09-29 07:07:59 +00:00
João MouraandClaude Opus 5.5	19d2ebcc8c	fix(cli): crewai eval exits 1 unless the gate passed, and says to log in when nothing was traced unattended (#7806) ... * fix(cli): `crewai eval` exits 1 unless the gate passed, and says to log in when nothing was traced unattended The exit code is what a CI job reads, and it said only whether the evaluation finished: a run whose goal gate FAILED exited 0, so a pipeline gating on `crewai eval` waved it through. It is the gate's now — 0 only for PASSED; a failed gate, one without a verdict, and an evaluation that stopped are 1. The command's help says so. With no terminal and no login, an anonymous run's trace stays on the machine even with tracing on (nobody is there to approve the upload). `crewai eval` then told the user to turn tracing on, which they had — the same loop again. When tracing is on and nobody is logged in, it now says what traces an unattended run: `crewai login`. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(cli): an unreadable login is the reason given when nothing was traced unattended Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(cli): print the unattended reason as text, never markup Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-29 11:47:47 +05:30
Lorenze Jay	deaa71e168	[docs-freeze] docs: snapshot and changelog for v1.15.23 (#7805) 1.15.23	2026-09-28 21:14:14 +00:00
Lorenze Jay	c018da6546	feat: bump versions to 1.15.23 (#7804)	2026-09-28 21:10:58 +00:00
Lorenze Jay	d183aedbd8	ensure panel for viewing traces is visible (#7803)	2026-09-28 14:02:30 -07:00
João MouraandClaude Opus 5.5	4dcd19aa2e	fix(tracing): turning tracing on is the answer, and an Evaluate button in the TUI (#7765) ... * fix(tracing): turning tracing on is the answer; stop asking again Two things a user who ran `crewai eval` sees today. `crewai eval` offers to turn tracing on and run the crew. The run finishes — and the ephemeral buffer asks "Share this execution trace with CrewAI?", which is the same question again. Turning tracing on IS consent: `tracing_asked_for()` is true when `CREWAI_TRACING_ENABLED` says so or when `tracing=True` was passed in this context, and the buffer takes it as the answer. First-time auto-collection still asks, because nobody asked for that one. And the offer named the mechanism rather than the effect — "Turn tracing on (CREWAI_TRACING_ENABLED=true stays in .env) and run the crew now?", then "Tracing is on for this project (CREWAI_TRACING_ENABLED=true in .env)." The variable is how it works, not what the user is agreeing to; both lines now say what happens and leave the plumbing to the .env file it is written in. 491 telemetry tests and 62 eval-CLI tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tracing): the TUI's modal is a prompt too, and say where traces go Two follow-ups from running it. The terminal UI installs its own consent callback, so turning tracing on still bought a modal at the end of the run — the callback is consulted before the default prompt, and the check only guarded the prompt. A host's callback stays authoritative, because an embedder may answer no for reasons of its own; what changed is that the TUI's callback, which exists to ASK, now answers for itself when tracing was asked for. And having taken the variable out of the offer, the offer should say what saying yes means: "Turn tracing on and run the crew now? The run's trace is sent to CrewAI AMP", and afterwards "Tracing is on for this project — its runs are traced to CrewAI AMP." Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(tui): an Evaluate button beside View Traces and Deploy A run finishes in the terminal UI and the next question is usually "was that any good?" — which `crewai eval` answers, from the command line, about the run that just happened. The button is there now, with `e` bound to it. It behaves like Deploy rather than like View Traces: it leaves the UI and then runs the command, because `crewai eval` talks — it prints the link to follow, waits for the verdict and prints that — and none of it belongs inside a full-screen app. It calls `eval_crew()` itself rather than reimplementing any of it, so the button and the command can never say different things; a clean SystemExit is the command deciding, and a failure is reported without failing the run that already succeeded. Declarative flows get it too — same button, same tail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(telemetry): count `crewai eval`, not only the button that runs it The TUI's buttons each record a `cli_usage:` feature span, so the new Evaluate button was counted — but the command it runs was not, and most people will type `crewai eval` rather than press a button. Every evaluation now records `cli_usage:eval`; the button keeps its own `cli_usage:evaluate`, so the difference between the two is how many were started from the TUI. It counts the command and nothing about the run: no id, no project, no verdict. And it is wrapped like every other telemetry call here — a missing tracer or a refused span never stops an evaluation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(telemetry): say which run was evaluated, and by whom `project_id` already rides every span. What only this command knows is which run is being graded, whether the caller was logged in, and — when they are — which organization they are logged in to. A feature span can carry attributes now, and `cli_usage:eval` carries those three. What it does not carry is anything about the work: no inputs, no output, no verdict, no criteria. The execution id is the join key; what was found lives in AMP, where the evaluation itself is. An anonymous caller reports `authenticated=false` and an empty organization, and is not asked for one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Address the review: a terminal, a thread, and the right run Three findings worth acting on, one already fixed, and ruff. **The security review is right.** `prompt_user_for_trace_viewing` fails closed where no one can answer, so an anonymous run in CI has never uploaded. Treating the switch as consent everywhere would have changed that: a project `.env` copied into CI carries the variable, not the person. `tracing_asked_for()` now answers only where a prompt could have been shown — the double-ask this PR is for happens in a terminal, and nothing else moves. **The ContextVar never crosses the worker.** `set_tracing_enabled` runs in the crew's validator, on the thread the crew was BUILT on, and a flow never sets it at all — so `tracing=True` without the env var still opened the modal. The TUI reads the declaration off the object as well: the same yes, wherever written. **The button now names the run it watched.** `_chain_eval()` called `crewai eval` with no id, which looks up the last recorded run — a PREVIOUS run when this one was not traced, and an offer to run the crew again when there is no record at all. The TUI remembers what was recorded before the run, hands the new id to the command, and says "this run was not traced" rather than grading someone else's. **Already fixed**: telemetry is recorded after `get_or_create_project_id()`, not before — that moved when the span gained its attributes. 492 telemetry tests, 187 CLI tests. Ruff format and check clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Close all three doors the prompt closes, not just the terminal The security review named three places `prompt_user_for_trace_viewing` fails closed — no terminal, a suite under test, and a host that suppressed tracing messages — and the first pass only honoured the terminal. A run under test, or inside a host that asked for silence, could still have uploaded on the strength of a variable. The three conditions are one function now, `_prompt_can_be_shown()`, used by the prompt itself and by `tracing_asked_for`, so the rule and the prompt it answers cannot drift apart. Where the question could not have been put to anybody, there is nothing to answer and nothing leaves the machine. The terminal UI decides for itself, and says why: it silences crewAI's console to keep it out of its own layout, which is a reason a PROMPT cannot be shown, not a reason to ask a second time — it has a screen and somebody in front of it. 494 telemetry tests, 88 TUI tests. Ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Tests: a real session for the consent rule, and a laid-out screen for a click The rule that a declared CREWAI_TRACING_ENABLED needs no modal only holds where a prompt could have been shown, and a test suite is one of the places it could not — so the three cases about a real session say a person is here. The consent click waited for the screen, which is not the same as waiting for its buttons to have a region; it now waits for the layout it clicks on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * A run started for an evaluation closes itself, even in a child process A project's crew and flow are run through `uv run …`, so the app lives in another process and the ContextVar saying "an evaluation is waiting" never reaches it: the screen stayed open and `crewai eval` waited behind it, which is the trap the handshake was meant to remove. The environment is the one thing that crosses into that process, so the command sets a variable there and clears it after; the id travels back the way it already did, through the project's last-run record. A run that FAILED leaves too — the command behind the screen has its own way of saying there is nothing to grade, and it cannot say it while somebody has to quit a screen first. And the spans a run exports reach AMP a moment after the run ends, sometimes later than that, so a command that just watched the run would ask for a trace still in flight and be told, correctly and uselessly, that there is nothing there. A run we know is fresh now waits up to two minutes and says it is waiting; an id somebody typed fails at once, as it always has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The evaluation happens in the app, on the screen the reader is already on Closing the app the moment the run ended and leaving somebody in a bare terminal, waiting some seconds for a link to appear and a browser to open, is worse than the screen it replaced. So the evaluation runs where the run does: `Evaluating this run` under the run's own line, the report link beside it, the browser opened from there, and `Goal gate PASSED · goal 5/5 · …` when it comes back. Nothing closes; the reader leaves when they are done reading, and the link is printed once more on the way out so it outlives the screen. The Evaluate button does the same thing now instead of quitting the app and chaining into the command, so there is one implementation of one experience — `_chain_eval` and `_want_eval` are gone. Pressing it again opens the report it already made rather than paying for a second evaluation. Underneath, `crewai eval`'s two steps became callable as values: they raise `EvaluationStoppedError` with the sentence to show instead of printing and exiting, and `evaluate_run()` is the app's one door — the url as soon as AMP gives it, every unfinished answer while it waits. The command keeps the terminal wording it had; when it ran the crew itself, it now has nothing left to say and steps aside for the app it opened. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The button says which report it opens Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The button works while it waits: it spins, and it stays pressable A dimmed label that never moves reads as a screen that has stopped. The Evaluate button now carries the same spinner the run's own line does, the clock goes back up to eight frames a second while the evaluation runs, and the button is no longer disabled — the report page is where the progress is, so pressing it while it waits is the useful thing to do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * View Traces opens the traces The button never had a link. crewAI grants one for every exported run and prints it after a run — but never under a TUI, where its console is kept out of the layout — so the app had nothing to open and said so, which read as a feature that had stopped working. The link is now recorded beside the rest of what crewAI writes when a run's spans reach AMP, and the button reads it off that record, matched to THIS app's execution rather than to whatever ran last in the project. When there is no link the notice says which of the two reasons it is: a run nobody traced, or a traced run AMP granted no viewer for — only one of those is the reader's to fix. Verified against a real anonymous run: pressing `t` opens app.crewai.com/crewai_plus/ephemeral_traces/<id> and shows it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The review's five: a trust boundary, a fallback, a retry, an exit and a count **A project's `.env` cannot lend itself the login.** `evaluate_run()` built its AMP client after the project's `.env` had been loaded with override, so a `CREWAI_PLUS_URL` a project put there landed in the set of origins trusted with the saved `crewai login` bearer. The command reads that variable BEFORE the `.env` — a shell export is this machine speaking — but inside the app there is no such "before", so the variable is left out of the set entirely. The request still follows it; the credential does not. **A run no app evaluated is still evaluated.** The command returned as soon as a trace existed, assuming the app had graded it — but a conversational session never ends the way a crew does and a flow with human feedback takes the terminal instead, so `crewai eval` could exit 0 having graded nothing. The app now leaves a marker naming the run it started evaluating, and the command grades anything that marker does not name. **An evaluation that stopped can be tried again.** The button re-enabled itself after a failure but the action still treated any existing evaluation as finished, so a 502 could only be escaped by re-running the crew. **A login that exits is shown on screen.** `saved_login()` fails by exiting, which is not an `Exception` and so slipped past the worker's hands: the button could sit on "Evaluating…" forever with the reason gone with the exit. **An evaluation the app runs is counted.** `cli_usage:eval` is the count of evaluations that begin, and the ones that begin in the app were missing from it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * A stop is a sentence, and the app's own word settles what it graded **"1" is not a reason.** A credential that exists but cannot be read stopped the evaluation by printing its sentence and exiting — under the app the print lands beneath the layout and the exit carries only a code, so the screen said `1`. `saved_login()` now raises the stop like everything else that stops an evaluation, the command catches it where it builds the client and prints it as before, and the app shows it. The test that claimed to cover this raised a `SystemExit` carrying a sentence, which is not what `_fail` raises; it now breaks the credential store and reads what reaches the screen. The worker still catches an exit, and says that the reason did not survive rather than echoing its code. **The record is the project's last finish, not this run.** Another run finishing in the same project replaces it while the app is open, so "is the marker about the id in the record" could send the command off to evaluate a different execution. The marker is now the app's own word about the run it watched — the id it evaluated, or null when it looked and found nothing to grade — and the command trusts it over the record, matching on time rather than on an id that may already have been overwritten. No marker still means no app got here, which is the conversational session and the flow that takes the terminal, and the command grades those itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * A project can say what good means, and `crewai eval` carries it An evaluation grades a run against the crew's own `expected_output`s — which is the prompt that produced the output, so it catches a crew that ignored its own contract and nothing else. What discriminates lives in criteria somebody writes, and there was nowhere to write them. Now there is. After the first evaluation the criteria it used are written to `eval.jsonc` in the project — once, never over a file that exists, because the one thing worse than no criteria is criteria that vanish whenever somebody evaluates — and the line that says so points at what to do with it. From then on the file travels with every evaluation, as it was written, comments and all: what a criterion means is the grader's to read, not this command's. Both doors do it, since most evaluations now happen inside the run app: the app writes the file and names it in the line that outlives its screen, and `crewai eval` in a terminal says it there. The file is bounded at the same 64KB AMP holds the field to, so one that would be refused is never uploaded and the run is graded anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * The review's asks: anonymous eval stats, a handshake a project cannot forge Usage stats are anonymous, so the `crewai eval` count says whether the caller was logged in and nothing else — no execution id, no organization (the product decision on this PR). Which runs were evaluated, and by whom, is AMP's record. A feature span now keeps only the keys its own feature lists, in both telemetry classes; everything else — the dimensions every span carries included — is dropped. The run app's "an evaluation is waiting" handshake was an environment variable any project's `.env` could set, which would start an evaluation with the machine's login on a plain `crewai run`. Its value is now a random token that counts only while the command's file of that name exists in the user's crewAI data directory; a `.env` cannot create a file. And three smaller ones: when no app evaluated the run, the command grades the project's record only if it was written after this run began; the "Wrote eval.jsonc" line after the app closes now appears (the key it read was never set); an oversized eval.jsonc is said once, through the caller's note, rather than printed under the TUI on every retry. uv.lock is back to main's: the change was re-resolution drift, nothing this PR needs. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * A report link is a web address, and an anonymous request names no organization Two from the security review of 52fa5f3ae. The report url comes from whichever AMP answered — which a project's `.env` may choose — and is printed as a link and opened without a click. It is now checked where it arrives, before anything shows or opens it: HTTPS, or plain HTTP to this machine, no credentials in it, no control characters. Anything else costs the link and nothing more. The host is not pinned: the report is served by the evaluation service, not by AMP. A request sent without the login — nobody logged in, or an AMP this machine is not logged in to — no longer carries the saved organization id. AMP reads it only beside a credential, so it said nothing to AMP and told an AMP the login does not go to which organization was asking. Dropped, as anonymous trace grants already drop it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-28 11:28:52 -07:00
Vidit Ostwal	4ed2abc7bb	fix(llm): retry throttled provider calls (#7677) ... * feat(llm): add rate limit retry policy foundation * feat(llm): retry rate limited client calls * fix(llm): keep throttles out of context recovery * refactor(llm): use throttling classifier directly * refactor(llm): clarify retry scope name * test(llm): keep retry coverage provider neutral * refactor(llm): simplify retry defaults * refactor(llm): encapsulate throttling retries	2026-09-25 18:00:20 +00:00
Vidit Ostwal	0e6440b397	docs(cli): guide assistants to platform tools (#7581) ... * feat(cli): prioritize platform integrations * docs(cli): guide assistants to platform tools * test(platform): update missing token assertion * fix(platform): retain integration token environment key * chore: ignore Codex workspace files * feat(platform): expand integration catalog * feat(platform): show integration action counts * feat(platform): select agent actions separately * feat(platform): group integration applications * fix(cli): keep platform picker navigation in place * fix(cli): validate platform apps once * fix(platform): use one integration token variable * test(platform): update integration token assertion * fix(cli): clarify platform token validation * fix(cli): show platform token prompts * refactor(platform): expose application catalog * refactor(platform): export catalog from Python * docs(platform): document catalog regeneration * fix(platform): resolve catalog type export	2026-09-25 23:24:59 +05:30
Vidit Ostwal	a2ea278210	feat(cli): prioritize popular platform integrations (#7573) ... * feat(cli): prioritize platform integrations * test(platform): update missing token assertion * chore: ignore Codex workspace files * feat(platform): expand integration catalog * feat(platform): show integration action counts * feat(platform): select agent actions separately * feat(platform): group integration applications * fix(cli): keep platform picker navigation in place * fix(cli): validate platform apps once * fix(platform): use one integration token variable * test(platform): update integration token assertion * fix(cli): clarify platform token validation * fix(cli): show platform token prompts * refactor(platform): expose application catalog * refactor(platform): export catalog from Python * docs(platform): document catalog regeneration * fix(platform): resolve catalog type export	2026-09-25 21:55:23 +05:30
Vidit Ostwal	dd4a106291	fix(bedrock): fall back to sync calls from acall (#7680)	2026-09-25 04:07:31 +00:00
Craig Estep	7060bf858b	Merge pull request #7717 from crewAIInc/security-policy-update ... Security policy: security@ and private vulnerability reporting	2026-09-23 21:37:09 +00:00
5 people	6536114451	fix(deps): pin instructor <1.16 to keep OpenAI Mode.TOOLS registered (#7719) ... * fix(deps): pin instructor <1.16 to keep OpenAI Mode.TOOLS registered instructor 1.16.0 removed the OpenAI Mode.TOOLS handler in favor of Mode.RESPONSES_TOOLS. `InternalInstructor` calls `instructor.from_provider`, which still defaults to Mode.TOOLS internally, so any native-OpenAI kickoff that hits a structured-output path (guardrails, output_pydantic, LLM guardrails) fails immediately with `ModeError: Mode.TOOLS is not registered for provider Provider.OPENAI`. Cap the range while we teach `_create_instructor_client` to negotiate a supported mode against `mode_registry`. Refs COR-861 (Docusign, deployment 134108). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: avoid redundant cache saves in tests workflow Co-authored-by: vinibrsl <5093045+vinibrsl@users.noreply.github.com> * docs: explain instructor compatibility pin Co-authored-by: vinibrsl <5093045+vinibrsl@users.noreply.github.com> --------- Co-authored-by: Daniel Minella <dminella@Mac.home> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>	2026-09-23 07:17:08 +05:30
João MouraandClaude Opus 5	bdd1bc6200	chore(cli): move crewai eval under experimental (#7707) ... Nothing about the command changes. It is still `crewai eval`, still listed in `--help`, still takes `--run`, still prints the same lines. Only the module moved, from `crewai_cli/eval_crew.py` to `crewai_cli/experimental/eval_crew.py`, with its tests alongside. The package says what the command's location could not: its output and its options may change between releases without the deprecation cycle a settled command gets. That is honest about where it stands — most of what it depends on lives outside this repository, in an AMP endpoint and the evaluator behind it, and both are new enough that the report's shape is still moving. The command is already built to absorb some of that, printing whatever the evaluation graded rather than a list of its own, but the promise it makes to a user should match. `crewai/experimental/` has the same role on the library side, so this is the convention the repository already has rather than a new one. The CLI had no experimental package before; it does now, and `crewai eval` is its first tenant. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:41:50 -07:00
João Moura	9de80df7f3	fix(cli): print whatever areas the evaluation graded (#7701) ... `crewai eval` printed a fixed tuple of area names. The areas belong to the evaluation, not to the client, so a fixed list does two wrong things the moment the evaluator's vocabulary moves ahead of an installed CLI: it drops every area it has not heard of, and it invents "not measured" for ones that no longer exist. A user would see one real grade and three phantom blanks, with no sign that anything had been dropped. It now prints the areas it was sent, in the order they arrived. The verdict is still validated exactly as before — a grade is an int in 1..5 or null — so a malformed payload is still a protocol error rather than something printed. This lands before the evaluator's own change so that an installed CLI keeps working through the rollout rather than after it.	2026-09-21 23:23:21 -07:00
João MouraandClaude Fable 5.1	0a3b8912b3	feat(cli): crewai eval evaluates the last traced run through AMP (#7649) ... * feat(cli): crewai eval evaluates the last traced run through AMP `crewai eval` reads `.crewai/last_run.json` — the record crewAI writes when a traced run's spans reach Wharf — and asks AMP to evaluate that run: POST /crewai_plus/api/v1/tracing/evaluations with the execution id, sending the saved `crewai login` when there is one and nothing otherwise. AMP answers with an evaluation id and a URL; the command prints the URL, opens it, waits for the verdict and prints it (goal gate and the four grades), exit 1 only when the evaluation itself failed. `--run EXECUTION_ID` evaluates another run. With no traced run recorded it offers to turn tracing on for the project (`CREWAI_TRACING_ENABLED=true` in .env, set_key so nothing else in the file moves) and run the crew now with `crewai run`; without a terminal, or declined, it prints the three steps instead. A run that leaves no record behind is explained, never guessed at. AMP's refusals are printed in its own words: a run that needs an account (401 account_required), a refused credential (then `crewai login`), a run AMP does not hold (404), rate limiting (429 with Retry-After), and any other status with AMP's message. The two AMP calls live on the CLI's PlusAPI subclass, so no crewai-core release is needed. Who may evaluate what is AMP's decision, not the command's: an anonymous run once without an account, then it needs one; a run traced while logged in for that organization's members; a deployment execution for members who may see its traces. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): crewai eval — guard the project, survive AMP blips, name the right subject, read the whole record Review findings, each reproduced before the fix: - The run-it-now offer wrote CREWAI_TRACING_ENABLED into ./.env before checking the directory is a crewAI project, then run_crew() died on a missing pyproject.toml with a traceback. Now: no pyproject.toml → one sentence, exit 1, nothing written. - httpx errors (AMP unreachable, a timeout) surfaced as tracebacks. Now the start says "Could not reach AMP to start the evaluation: …"; while waiting, an unreachable AMP or a 5xx is retried up to POLL_RETRIES consecutive times, then reported with the URL — the evaluation keeps running server-side either way. - The POST now carries a 120 s timeout (AMP reads the run's spans inside it), the poll 30 s. - A 200 whose body has no known status (a non-dict, no status, a status outside queued/running/done/failed) polled forever. Now it stops with the status it saw and the URL. - A 404 without a JSON message read "AMP holds no run <evaluation id>" while polling. _refused takes "run <id>" / "evaluation <id>" and says "AMP answered 404 for <subject>" — AMP's own message still wins. - The record's amp_base_url was ignored; the CLI now evaluates the run at the AMP it was traced to. --run keeps the configured AMP. - The post-run explanation names the third cause: a crewai older than the version that records the last run. Tests for each, plus the previously untested paths: Ctrl-C exits 130, a 2xx without an id, a refusal mid-poll, DMN opens no browser, --run skips the offer. 51 passed in lib/cli/tests (eval + plus_api). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): crewai eval — the credential goes only to the configured AMP; an explicit yes before running the crew; a done answer needs a well-formed verdict Review findings (CodeRabbit, the PR gate): - The record's amp_base_url was handed to PlusAPI beside the saved login, so a modified .crewai/last_run.json could send the token to any origin. The client is now built from the configured AMP only (CREWAI_PLUS_URL, the saved settings, app.crewai.com); the project's .env is loaded first, as `crewai run` loads it, so the configured AMP is the one the run was traced to. A record naming another address gets a one-line note and no credential. - The offer to turn tracing on and run the crew defaults to no and says the .env change stays; Enter no longer spends a crew run. - A `done` answer whose verdict is missing or malformed (no gate, grades not an object, a grade not an int or null) is a protocol error, exit 1, instead of an INCONCLUSIVE line with exit 0 or an AttributeError. Tests for each: a foreign origin in the record with a saved token, the .env-loaded same-AMP case, seven malformed verdicts, the prompt's text and default. 59 passed (eval + plus_api); ruff and mypy clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): crewai eval — Enter accepts the offer to run the crew (y/n, Y default; the prompt names both effects) João's call (2026-09-20): the confirm is y/n with Y as the default. The prompt still says tracing stays on in .env and that the crew runs now. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-21 18:34:04 +00:00
João MouraandClaude Opus 5	6e1fa8cf2a	feat(tracing): record the last traced run for crewai eval instead of printing it (#7648) ... * feat(tracing): record the last traced run for crewai eval instead of printing it After a traced run, crewAI printed a panel with the execution id and a viewer link. The id is internal, and the panel exposed it for no purpose a user has. Nothing is printed now. Instead, once the run's spans have reached Wharf, crewAI writes `.crewai/last_run.json` in the project: the execution id, when the run started and ended, whether it was traced anonymously or under an account, and the AMP base url. `crewai eval` reads it back, so the user evaluates their last run without pasting anything. GrantSpanExporter.record_export replaces show_trace_summary at the two finish points (an authenticated run's shutdown, an anonymous run's share). Only a run whose every export succeeded is recorded — a partial export would name a run the grader could not read whole. Recording is silent in the TUI and under message suppression too, off under the test suite, and inert inside a deployment, where the platform binds the execution before crewAI's own tracing starts. The record is written atomically and a write failure never fails the run. The crew, flow and json_crew scaffolds now ignore `.crewai/` like the declarative flow scaffold already did. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(tracing): never record a truncated ephemeral run; resolve the record path inside the guard; pin the window and the once - An ephemeral buffer that dropped spans at its cap still uploaded the rest and recorded the run. The grader could not read that run whole, so it is no longer recorded (the upload still happens). Test added. - last_run_path() ran before the try in record_last_run; a cwd that vanished mid-run would have raised out of a function documented never to raise. It is inside now, with the same debug log and None. - Tests: the "recorded once" check counted an unchanged mtime, which proves nothing on a coarse filesystem — it now counts calls to record_last_run; the first-start/last-end fold across export batches had no value test — batches now arrive out of order and the ISO window is asserted. - Docs: the conversational-flows comment said "one trace link" for output that no longer exists; tracing.mdx now names .crewai/last_run.json, what it holds, who reads it, and when it is not written. en, ar, ko, pt-BR. 85 passed (test_session_trace_export + test_last_run); ruff and mypy clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(tracing): a temporary file of its own per writer; the docs name deployments - record_last_run wrote every record through one `.tmp` name, so two crews finishing together in one project could replace each other's temporary file and one record was lost. Each write now goes through tempfile.mkstemp in the same directory, then os.replace; a failed write removes its own temporary file. Tests: two writers use two names and leave only last_run.json; a failed replace leaves nothing behind. - tracing.mdx (en, ar, ko, pt-BR): nothing is recorded inside a deployment, where the platform owns the trace. 87 passed (test_last_run + test_session_trace_export); ruff and mypy clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(tracing): the run that finished last stays recorded, whichever writer comes last Two crews finishing together in one project: the older run's writer could reach the file after the newer one and leave the older run as "the last". record_last_run now compares finished_at (recorded_at when absent) with the record already there and keeps the later-finished run; the same run recorded again (a refreshed grant) and a record without a comparable time never block the run just finished. No lock file: the file is a convenience pointer and the compare closes the ordering, leaving a microsecond window between read and replace that two runs finishing in the same instant could hit — either is then a fair "last run". Test: the older writer replaces after the newer one; the newer stays. 88 passed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(tracing): a same-millisecond tie keeps the record already there; nothing is recorded inside a deployment - The times in the record are stored to the millisecond; two runs finishing in the same millisecond compared equal and the later writer won, which could leave the older run recorded. A tie now keeps what is there. No finer order is worth a field in the file. - recording_enabled() is false when the platform's integration token is present: a deployment normally never reaches this code (the host binds the trace before crewAI would start its own), but a container that did not would have written a file the platform never reads, against what the docs promise. Test added. 89 passed; ruff and mypy clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(tracing): only a run that provably finished later holds the record My previous commit compared `finished_at` and fell back to `recorded_at`, which broke two existing tests on CI: two records written in the same millisecond with no completion time compared equal, so the second write was dropped and the older run stayed. Locally the two writes happened to land in different milliseconds, so the suite passed — a timing-dependent bug, not a CI quirk. The rule is now narrow: a write stands unless the record already there is a DIFFERENT run with a later `finished_at`. No completion time on either side, the same run recorded again, or a tie to the millisecond all leave the write to stand, so "the last run recorded" stays what a reader gets. The case the rule exists for is unchanged: the older-finished writer arriving last does not replace the newer one. 485 passed in lib/crewai/tests/telemetry (test_last_run run five times for timing); ruff and mypy clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tracing): serialise the write across processes; drop the platform-token guard, which was not a deployment test - Reading the record, deciding and replacing it are now one step, held under a lock file beside the record, so a writer can no longer decide against a record another process has already replaced. Where the platform has no flock the write goes ahead unserialised: the record is a convenience pointer for `crewai eval`, never worth failing a run over. The regression drives three writers at once and fails without the lock. - The deployment guard I added yesterday read CREWAI_PLATFORM_INTEGRATION_TOKEN, which is not a deployment marker: `crewai create crew` writes that token into a project's own .env for platform tools, and crew_base loads it, so the guard would have stopped recording for every developer who uses them. It is also unnecessary — a deployment kicks off with tracing off, so crewAI never builds the exporter and never reaches this module. Guard removed, with a test that a project carrying that token is still recorded. - The module docstring claimed the platform "binds the execution before crewAI would start its own tracing". It does not; it sets tracing off at kickoff. Docstring and the four tracing docs now say the real reason. 487 passed in lib/crewai/tests/telemetry; ruff and mypy clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tracing): a refused lock still records the run; the platform-token test exercises the real guard Two Cursor findings on the locking commit. - If flock itself failed — some network mounts refuse it — the OSError escaped _exclusive, the outer handler deleted the temporary file and record_last_run returned None, so the run was not recorded at all. A refused lock is now logged and the write goes ahead unserialised, matching what already happened when the lock file could not be opened or flock does not exist. Unserialised beats not recorded. - test_a_project_using_platform_tools_is_still_recorded used the `project` fixture, which stubs recording_enabled — the very thing under test — so the regression it guards could have come back green. It now stubs only project_dir and asserts the real guard. 13 in test_last_run, 489 across lib/crewai/tests/telemetry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-21 17:28:25 +00:00
3 people	784aadde1d	fix(tools): keep selenium driver reusable (#7663) ... Co-authored-by: gaoanze <gaoanze@meituan.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-21 10:58:22 +00:00
gaoanze888andgaoanze	9c1275cc8f	fix(tools): close S3 response bodies (#7647) ... * fix(tools): close S3 response bodies * fix(tools): preserve S3 reader outcomes --------- Co-authored-by: gaoanze <gaoanze@meituan.com>	2026-09-21 16:11:45 +05:30
João MouraandClaude Fable 5.1	0374c63129	feat(tracing): task spans say the declared output format and what came out, agent spans carry the prompt and answer, tool spans say whether the cache answered (#7597) ... * feat(tracing): record the task's declared output format, the agent's prompt and answer, and the tool cache flag on their spans A reader of a run's OTel spans could see a task's raw output but not the format it declared, nor whether a Pydantic object or a JSON dict actually came out of it; could see an agent's goal, backstory and model but not the prompt it was handed or the answer it gave; and could see a tool's result but not whether the tool ran or the cache answered. execute task: crewai.task.output_format (json / pydantic / raw; from the declaration on start and failure, from the TaskOutput on completion), crewai.task.output_pydantic_produced, crewai.task.output_json_produced. execute agent: gen_ai.input.messages carries the task prompt and gen_ai.output.messages the answer, the spec shape the task span already uses for its own text, under the existing per-attribute byte cap with the .truncated / .original_size_bytes markers when cut. call tool: crewai.tool.from_cache. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(tracing): the agent's prompt and answer leave under the two standard message keys and no other Pins the review decision on #7597: the text travels as gen_ai.input.messages / gen_ai.output.messages — the keys the call llm span already exports its messages under — so a rule an exporter or a redaction processor applies to LLM content by key name applies to the agent span unchanged. A copy under a crewai.agent.* key would fail this. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-19 19:38:04 -03:00
Lorenze Jay	3831e8b6c8	ensure link is shown after finalizing traces (#7593)	2026-09-18 20:13:44 -03:00
João MouraandClaude Fable 5.1	bbcebffbf9	fix(llm_overlay): a role and a key that differ only by surrounding whitespace match (#7572) ... * fix(llm_overlay): a role and a key that differ only by surrounding whitespace match A role that comes from a YAML file often ends in a newline — `role: >` folds to "Researcher\n" — and a caller writes the key for the clean text, "Researcher". The two never matched, so the agent kept its declared llm without a word: the overlay looked active and did nothing. `llm_overlay(mapping)` now sets a copy of the mapping with the whitespace around each key dropped, and `overlay_model_for(role)` strips the role before looking it up; an empty or None role matches nothing. Matching is otherwise unchanged: exact text, no case folding. The mapping the caller passed is not touched. The three readers (Agent at construction and after interpolation, LiteAgent at construction) already go through overlay_model_for, so they pick this up with no change of their own. Tests: a key "Researcher" matches "Researcher\n" and " Researcher "; a key written with a trailing newline matches a clean role; case and inner whitespace still miss, as do "" and None; the caller's mapping is not mutated; a YAML-folded template role matches after interpolation. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(llm_overlay): two keys that are one role with different models are refused Review on #7572 (CodeRabbit, iris-clawd): after stripping, "Researcher" and " Researcher " are one key, and the later entry silently won — the model an agent ran on depended on dictionary order. `_stripped` now refuses a mapping that names one role twice with different models (ValueError naming the role and both models) and keeps a harmless duplicate that names the same model once. A test pins both. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-18 10:02:33 -03:00
Vidit Ostwal	17feaf48fb	fix(deps): upgrade soupsieve security patch (#7571)	2026-09-18 09:13:52 +02:00
João MouraandClaude Fable 5.1	c3f83cd866	feat(llm): re-resolve llm_overlay after input interpolation rewrites an agent's role (#7518) ... * feat(llm): re-resolve llm_overlay after input interpolation rewrites an agent's role llm_overlay (#7500) resolves an agent's model at construction, by its role text. A CrewBase crew declares roles as templates in YAML — "Researcher for {repo}" — that Crew._interpolate_inputs rewrites at kickoff, after construction. An overlay keyed by the interpolated role, which is the text every trace records, never matched: on a production flow a plan routed 3 of 5 agents and left the two templated ones on their declared model. Agent.interpolate_inputs now looks the overlay up again when the rewrite changed the role: a key sets llm to the mapped model (create_llm, as construction does), carrying the streaming flag Crew.kickoff(stream=True) set on the instance it replaces; a miss, no active overlay, or an unchanged role leaves llm exactly as it is — construction's resolution and instance stand, nothing reverts. The executor binds agent.llm per task, after interpolation, so the task runs on the new model (pinned through prepare_kickoff). Not followed by the swap, documented: a task's string guardrail LLM, an auto-created Memory LLM, the crew_creation span. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(llm): read llm_overlay once per agent — a re-validation must not replace an llm the agent already runs on Found while battle-testing the previous commit with real calls: the event bus registers an agent in its RuntimeState the first time it emits, and RuntimeState(root=[agent]) re-runs Agent.post_init_setup on the same object. Inside a block that maps the agent's role, the construction-time overlay read (#7500) then replaced the llm the agent was already running on and dropped the state set on it (stream=True). An agent built outside the block picked the mapped model up on its second standalone kickoff inside one, against #7500's own contract; Crew.replay inside a block did the same. A private flag marks the construction-time read as done; a re-validation keeps the llm the agent has — the one construction resolved, or the one interpolate_inputs set when the role changed. Copies (kickoff_for_each) are new instances and read the overlay as before. Zero-cost tests through RuntimeState; docstrings corrected (a crew Memory built at kickoff does follow the swap; a stream must be iterated inside the block). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-17 16:54:00 -03:00
Vidit Ostwal	977aa0c6ec	feat(cli): improve platform integration setup UX (#7453) ... * fix(cli): silence tool import warnings during platform setup * feat(cli): validate platform integrations concurrently * fix(cli): persist platform token during crew setup * fix(core): make settings write probe concurrency-safe * test(cli): simplify event loop fallback stub	2026-09-17 11:35:32 -07:00
3 people	597b99fb57	fix(tools): preserve directory listing paths (#7548) ... Co-authored-by: gaoanze <gaoanze@meituan.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-17 22:47:38 +05:30
3 people	b9629cfb8f	feat: add native Gemini 3.8 Flash support (#7284) ... * feat(llm): add Gemini 3.8 Flash support - Register Gemini 3.8 Flash in CrewAI and CLI model catalogs - Add 1,048,576-token context window mapping - Add native Gemini provider support - Add Gemini 3.8 Flash to the CLI model picker - Add native model detection coverage for gemini/ and google/ formats - Add context window regression coverage Closes #7241 * test: add VCR cassette for gemini-3.8-flash * chore: stop tracking .env.test * Bringing back .env.test --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com>	2026-09-17 08:59:36 -07:00
Sharoon SharifandVidit Ostwal	5c33fe4c71	fix: close sqlite connections in flow persistence and sqlite provider (#7511) ... Apply the same contextlib.closing pattern accepted in #7493 to the nine remaining library-side sqlite3.connect sites: SQLiteFlowPersistence (init_db, save_state, load_state, save_pending_feedback, load_pending_feedback, clear_pending_feedback) and SqliteProvider (checkpoint, prune, from_checkpoint). The connection context manager only commits or rolls back, so the connections survived in a reference cycle and kept flow_states.db / checkpoint databases locked on Windows. Also close the read-back connections in test_checkpoint.py, which made its TemporaryDirectory cleanup fail on Windows for the same reason. Add lifecycle and failure-path regression tests. Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-17 07:37:38 +00:00