Symptom
prompt_for_inputs writes the field prompt onto stdout. A wrapper that then prints JSON gets topic > \x1b[0m{"topic": "AI"}\n and json.loads fails with Expecting value: line 1 column 3 (char 2) even when the process exits 0.
Evidence what you'll see
- On Windows with Click 8.4.2 the observed streams were stdout
topic > \x1b[0m{"topic": "AI"}\nand stderr\n Crew inputs\n Required values\n. - The helper's title, subtitle, and description already use
err=True; itsclick.promptcall did not. - Reproduced on
main@c6e500ab3730ccf3badb640c6e0170e5c6aa3882withcrewai-cli1.15.28. JSON crew and declarative-flow input resolution both use this helper.
Why it happens
The field prompt went to stdout, so a consumer could not parse the serialized result. Pull request 8297 passes err=True to Click and, on Windows, redirects stdout only during the prompt because Click 8.4.2 still writes the last prompt character through input() on stdout.
Affected versions
crewai-cli 1.15.28 on an editable main checkout at c6e500ab3730, Click 8.4.2, native Windows, Python 3.12.8. crewAI Tools is not used.
Fix steps
0 of 2 done
Your check marks stay in this browser only.
How to check it worked
- The same wrapper's stdout is exactly
{"topic": "AI"}\nandjson.loads(result.stdout)succeeds.
If it still fails
- No published release tag contains pull request 8297. Tag
1.15.28was compared against merge37f0bd32ceand does not contain it. - The report says this is the helper's I/O contract, not a claim that every
crewai runresult is JSON. Existing tests that replaceclick.promptdo not observe the real streams.
Sources and credit
Summarized in our own words from these public reports. Credit goes to their authors.
Provided as is, without warranty. Try changes in a non-production environment and back up first. Security-related steps: verify against the official docs. Terms · Request removal or attribution change
Hit an error we don't cover? Submit it