Conversation
E2E VerificationCLI source verification ( export const EXTERNAL_PERMISSION_MODES = [
'acceptEdits',
'auto',
'bypassPermissions',
'default',
'dontAsk',
'plan',
] as const
TS SDK parity: TypeScript SDK v0.2.91 already added Note: Live e2e test with Generated by Claude Code |
E2E Test ResultsTest: CLI validation of
|
There was a problem hiding this comment.
LGTM — simple type annotation fix to sync Python SDK with CLI and TypeScript SDK parity.
Extended reasoning...
Overview\nThis PR modifies two files: adds to the Literal type in and adds a corresponding test case in . The change is purely additive and type-annotation-only — the SDK passes directly to the CLI subprocess without SDK-side validation.\n\n### Security risks\nNone. This is a type annotation change only. The CLI already accepts at runtime and validates it server-side. No auth, crypto, or permission logic is modified.\n\n### Level of scrutiny\nMinimal scrutiny required. The change is mechanical — it adds one string literal to a type and one test assertion. It's verified against the CLI source () and the TypeScript SDK which already has parity. The only bug found is a documentation nit (docstrings in and not updated), which is already captured as inline comments.\n\n### Other factors\nThe test coverage is updated to include the new value. The PR description provides thorough verification. The nit about missing docstring updates is minor and doesn't affect correctness.
There was a problem hiding this comment.
LGTM — both docstrings have been updated to include 'auto', addressing my prior feedback.
Extended reasoning...
Overview
This PR adds 'auto' to the PermissionMode Literal type in types.py, updates the docstrings in query.py and client.py to enumerate all six valid modes, and adds a test case. Four files are touched; all changes are documentation/type annotation only — no runtime logic is modified.
Security risks
None. This is a type annotation fix; the value is passed through unchanged to the CLI subprocess. No auth, crypto, or permissions logic is altered.
Level of scrutiny
Low. The change is purely additive (one new string literal, two docstring additions, one test assertion) and mirrors an existing TS SDK change. My previous review flagged the missing docstring updates; those have been addressed in the current diff.
Other factors
My prior inline comment flagged the docstring gap; the PR diff shows both query.py and client.py now include the 'auto' bullet. The test coverage is adequate. No outstanding concerns remain.
Live E2E proof (real API call)import anyio
from claude_agent_sdk import query, ClaudeAgentOptions, ResultMessage, SystemMessage
async def main():
opts = ClaudeAgentOptions(
model="claude-haiku-4-5",
permission_mode="auto",
max_turns=1,
)
async for msg in query(prompt="Reply with exactly: auto-mode-ok", options=opts):
if isinstance(msg, SystemMessage) and msg.subtype == "init":
print(f"init: permissionMode={msg.data.get('permissionMode')}")
if isinstance(msg, ResultMessage):
print(f"result: subtype={msg.subtype} is_error={msg.is_error} text={msg.result!r}")
anyio.run(main)Output (this branch, CLI 2.1.93): Before (main): mypy/pyright reject After (this branch): type checks pass; Generated by Claude Code |
Summary
Adds
"auto"to thePermissionModeLiteral type, bringing the Python SDK to parity with the TypeScript SDK (v0.2.91) and the CLI'sEXTERNAL_PERMISSION_MODES.Problem
The CLI binary (v2.1.90+) and the TypeScript SDK (v0.2.91) both support
"auto"as a valid permission mode, but the Python SDK'sPermissionModetype doesn't include it. Users who setpermission_mode="auto"get a type error even though the underlying CLI accepts it.Changes
src/claude_agent_sdk/types.py: Added"auto"toPermissionMode = Literal[...]tests/test_types.py: Added test case forpermission_mode="auto"intest_claude_code_options_with_permission_modeVerification
'auto'is inEXTERNAL_PERMISSION_MODESin the CLI source (src/types/permissions.ts)'auto'to its publicPermissionModetypepermission_modeas--permission-mode <value>to the CLI subprocess with no SDK-side validation — this is purely a type annotation fix