Repository navigation
Python: [Bug]: LocalShellTool's hosted type="shell" tool is not supported on gpt-6-luna-2026-09-22 #8914
Description
Description
LocalShellTool is advertised to the model API as a hosted type="shell" tool (as_function() tags it kind="shell", which the OpenAI client serializes to type="shell"). gpt-5.6-luna accepted this, but gpt-6-luna-2026-09-22 rejects it and every request 400s before any turn runs:
Error code: 400 - Tool 'shell' is not supported with gpt-6-luna-2026-09-22. (param: tools)
Since the tool actually runs locally via LocalShellTool.run(), the hosted type="shell" declaration isn't needed here — a plain type="function" tool would work on any model.
Request: let LocalShellTool be advertised as a plain function tool (type="function") instead of the hosted type="shell" surface — via an opt-in on get_shell_tool(...) / as_function(...), or a fallback when the model doesn't support the hosted shell tool.
Code Sample
# Self-hosted Foundry agent with a LOCAL shell tool over a per-session sandbox.
shell = LocalShellTool(
mode="persistent", workdir=run_dir, confine_workdir=True,
approval_mode="never_require", acknowledge_unsafe=True,
)
agent = create_harness_agent(
client=FoundryChatClient(
project_endpoint=..., model="gpt-6-luna", credential=DefaultAzureCredential()
),
shell_executor=shell,
default_options={
"store": False,
"allow_multiple_tool_calls": True,
"reasoning": {"effort": "medium"},
},
)
ResponsesHostServer(agent).run()
# The shell tool is serialized as hosted type="shell" (because as_function() sets kind="shell"),
# and the first model call 400s: Tool 'shell' is not supported with gpt-6-luna-2026-09-22.Error Messages / Stack Traces
agent_framework.exceptions.ChatClientException: ("<class 'agent_framework_foundry._chat_client.FoundryChatClient'> service failed to complete the prompt: Error code: 400 - {'error': {'message': "Tool 'shell' is not supported with gpt-6-luna-2026-09-22.", 'type': 'invalid_request_error', 'param': 'tools', 'code': None, 'request_id': 'fd6660e6e3f1b82fb4a91d2e1372b263'}}", BadRequestError("Error code: 400 - {'error': {'message': "Tool 'shell' is not supported with gpt-6-luna-2026-09-22.", 'type': 'invalid_request_error', 'param': 'tools', 'code': None, 'request_id': 'fd6660e6e3f1b82fb4a91d2e1372b263'}}"))Package Versions
agent-framework-core: 1.19.0 agent-framework-openai: 1.14.4 agent-framework-foundry: 1.13.1 agent-framework-foundry-hosting: 1.0.0b260918 agent-framework-tools: 1.0.0b260918 agent-framework-monty: 1.0.0b260918 openai: 3.16.2
Python Version
3.11.16
Additional Context
- gpt-6-luna-2026-09-22 rejects the hosted type="shell" tool on the tools param; gpt-5.6-luna accepted it.
- Related: Python: [Bug]: LocalShellTool never executes on a self-hosted Foundry agent since openai 1.14.4 - "No tool output found for shell call" #8663 (same kind="shell" -> hosted-shell coupling, different symptom) and .NET: [FoundryAgent][gpt-6-luna]: [Bug]: Invalid parameter: 'text.format' of type 'json_schema' is not supported with model version
gpt-6-luna-2026-09-22#8718 (same model, different unsupported param: text.format json_schema).
Metadata
Metadata
Type
Projects
- Status
Activity
manjunathshiva commentedon Oct 1, 2026
Hi Eduard van Valkenburg (@eavanvalkenburg), I'd like to help with this. I'm checking first because it sits on the hosted/local shell boundary in
docs/specs/004-python-function-calling-loop.md.It's broader than gpt-6-luna. On an Azure OpenAI gpt-5-mini deployment,
create_harness_agent(..., shell_executor=LocalShellTool(...))fails every request with400 Tool 'shell' is not supported with gpt-5-mini-2025-08-07before any turn runs. The same executor declared astype="function"works: the model returns afunction_call, and with the defaultapproval_mode="always_require"it stops at afunction_approval_request.Why an opt-in needs two small pieces. Both providers turn
kind="shell"into their native tool (type="shell"for OpenAI/Foundry,bash_20250124for Anthropic).LocalShellTool.as_function()already carries that kind, and the harness always goes throughclient.get_shell_tool(...). So the change would be anas_function()option that returns an ordinary function tool, with the same approval mode and sandbox, plus acreate_harness_agentoption that uses it. Response classification doesn't change, so it doesn't overlap #8720. I'd avoid an automatic fallback on the 400.The part that's your call: in function mode, local shell runs through an ordinary function call. The #8294 guard is unaffected (with the tool configured as a shell, a
function_callnamed after it is stillinformational_only), but function mode makes a generic function call the execution path. Is that acceptable to you, and is this the shape you'd want?alkaiserItron commentedon Oct 1, 2026
Eduard van Valkenburg (@eavanvalkenburg) Why was this closed? I do not see a linked PR, was this addressed in a separate issue?