Repository navigation
Python: [Bug]: Update Monty Integration to support latest pydantic-monty APIs #8152
Description
Description
The agent-framework-monty integration currently appears to rely on APIs from older versions of pydantic-monty.
Newer versions of pydantic-monty have introduced API changes that are not currently reflected in the Agent Framework Monty implementation. At the moment, I need to explicitly pin:
pydantic-monty==0.0.18
to avoid compatibility issues.
The agent-framework-monty package currently declares pydantic-monty>=0.0.1,<0.1, so newer incompatible versions can be installed even though the integration appears to target the older API.
It would be great to update the Monty integration to support the latest pydantic-monty APIs and adjust the dependency bounds as appropriate.
For example, pydantic-monty has made changes to APIs such as ResourceLimits since 0.0.18, including removal of max_allocations in 0.0.19.
Expected behavior
agent-framework-monty should work with the latest supported version of pydantic-monty without requiring users to manually pin pydantic-monty==0.0.18.
Package Versions
agent-framework-core 1.16.0
Python Version
Python 3.11
Metadata
Metadata
Labels
Type
Projects
- Status
Activity
github-actions commentedon Sep 8, 2026
🤖 Automated triage reproduction notes (agent-authored — trust but verify)
Agent analysis
Repro:
python/packages/monty/agent_framework_monty/_monty_bridge.py::InlineCodeBridge.runat line 232 passes source code positionally topydantic_monty.Monty, triggeringTypeErrorwith allowed release 0.0.23 before execution begins. Minimal repro: on Python 3.11 installagent-framework-montywithpydantic-monty==0.0.23and runawait InlineCodeBridge({}).run("print('hello world')"); the existingtest_plain_python_print_round_tripsalso fails.python/packages/monty/tests/monty/test_monty_codeact_integration.py::test_plain_python_print_round_trips1.16.01.0.0b260730FOWEPJF255 commentedon Sep 8, 2026
I'd like to work on this.
Root cause:
pydantic-monty>= ~0.0.19 is a worker-pool API (Monty()/checkout()/feed_start()), so the oldMonty(code).start(...)path inInlineCodeBridgeraisesTypeError. Separately,feed_startalways surfaces OS calls as snapshots 鈥?mounts are applied viaresume_auto(), not a plainresume(...)rejection.Proposed fix (local, tested):
with Monty() as pool: with pool.checkout(...): session.feed_start(...).resume_auto(); otherwise keep the existingPermissionErrorbehavior.pydantic-monty>=0.0.23,<0.1and update ResourceLimits docs (max_allocationsremoved).Validation so far: hermetic
test_monty_codeact.pyand integrationtest_monty_codeact_integration.py(includingtest_plain_python_print_round_tripsand mount cases) pass againstpydantic-monty==0.0.23.Happy to adjust if you'd prefer a different approach.
Python: Refresh uv.lock for pydantic-monty>=0.0.23 (microsoft#8152)
Python: drop obsolete pydantic-monty version migration comment (micro…
Python: add uv.lock platform markers for monty deps (microsoft#8152)
Revert "Python: add uv.lock platform markers for monty deps (microsof…
Python: refresh uv.lock for pydantic-monty 0.0.23 (microsoft#8152)
Python: Update Monty bridge for pydantic-monty pool API (microsoft#8152…