Fail faster when json.loads is doomed#678
Open
lukeyoung100 wants to merge 1 commit intoanthropics:mainfrom
Open
Fail faster when json.loads is doomed#678lukeyoung100 wants to merge 1 commit intoanthropics:mainfrom
lukeyoung100 wants to merge 1 commit intoanthropics:mainfrom
Conversation
Context:
I had an issue in my local setup where I added a hook which outputs a \a character with claude's output to trigger a bell when claude is finished answering a question e.g.:
19 "hooks": [
20 {
21 "type": "command",
22 - "command": "printf '\\a' >&2; echo -ne '\\a' > /dev/tty 2>/dev/null; echo -ne '\\a' > /proc/$PPID/fd/1 2>/dev/null"
23 }
24 ]
This triggered a failure scenario where my myclaw daemon was attempting to talk to claude in json format but instead of line 557 running json.loads('{key:value...etc}') it was failing with json.loads('\a{key:value}'). This caused the daemon to hang for 10 minutes.
When I add the exception here it causes the claude sdk to give up way faster. I no longer experienced 10 minute hangs when interacting with the daemon through gchat. Instead the error message shows up in the logs and I experienced only slightly delayed messages.
dotuananh0712
added a commit
to dotuananh0712/claude-agent-sdk-python
that referenced
this pull request
Mar 15, 2026
When the buffer contains non-JSON content (e.g., control characters like \a from shell hooks), json.loads fails and the code continues waiting indefinitely for valid JSON, causing 10+ minute timeouts. This fix detects when the buffer contains non-JSON content at the start (after stripping whitespace) and raises SDKJSONDecodeError immediately instead of waiting forever. Fixes anthropics#678
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context:
I had an issue in my local setup where I added a hook which outputs a '\a' character with claude's output to trigger a bell when claude is finished answering a question e.g.:
19 "hooks": [
20 {
21 "type": "command",
22 - "command": "printf '\a' >&2; echo -ne '\a' > /dev/tty 2>/dev/null; echo -ne '\a' > /proc/$PPID/fd/1 2>/dev/null"
23 }
24 ]
This triggered a failure scenario where my myclaw daemon was attempting to talk to claude in json format but instead of line 557 running json.loads('{key:value...etc}') it was failing with json.loads('\a{key:value}'). This caused the json.loads to throw an exception, continue in the for loop, and execute a blocking wait on line 28, while it waits more data from claude that will never come. This caused the daemon to hang until a 10 minute timeout was hit.
When I add the exception here it causes the claude sdk to give up way faster. I no longer experienced 10 minute hangs when interacting with the myclaw daemon through gchat. Instead the error message shows up in the logs and I experienced only slightly delayed messages. I'm not 100% why I still got responses, but I suspect that in some retries the '\a' was mssing from claude's output for some reason.