claude-code - 💡(How to fix) Fix [BUG] False-positive AUP block on z/OS HLASM development, Opus 4.7, mid-session regression [1 comments, 1 participants]

Here's a fragment of the larger attached session copy:

● Bash(echo "=== local file bytes / encoding ==="; file /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c; wc -l -c /home/joede/git2026/zoweclang/zowe-common-…) ⎿  === local file bytes / encoding === /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c: C source, Unicode text, UTF-8 text 48 1485 /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c … +6 lines (ctrl+o to expand)

Called zos 2 times (ctrl+o to expand)

● Let me isolate whether it's upload-specific by creating a minimal file DIRECTLY on z/OS (not via upload) and compiling it.

Called zos 2 times (ctrl+o to expand)

● Upload-specific issue. Native-created file compiles fine; uploaded file can't be opened by ibm-clang64 despite looking normal. Let me compare the upload-created files against the native-created one at byte level.

● Calling zos… (ctrl+o to expand)

✻ Building configmgr with ibm-clang64… (1m 22s · ↑ 4.0k tokens · thought for 8s) ⎿  ✔ Fetch + checkout feature branch on z/OS ◼ Run build_cmgr_clang.sh zos on z/OS ◻ Functional test configmgr on z/OS ◻ Fix em-dash chars in source comments

❯ /effort ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ❯ Press up to edit queued messages ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── esc to interrupt · ctrl+t to hide tasks

● The EDC5122I Input/output error is the same charsets.c-style I/O failure — probably a file-tagging issue from my upload. Let me check the tag.

Called zos 5 times (ctrl+o to expand)

❯ If you make a file locally in UTF8 and you use zos_upload_files all should go well.

● Taking you at your word — UTF-8 local + zos_upload_files should be fine. So this I/O error is probably transient or something specific. Two things I'll do:

1. Fix the RC detection in the build script — | tee ... was eating the compiler exit code, so the rc=0 was misleading. Using PIPESTATUS[0].
2. Suggest a fresh re-upload, since I don't see anything wrong with the local file and your observation is that the upload-to-compile path normally works.

● Write(build/build_hlasm_mini.sh) ⎿  Added 3 lines, removed 4 lines 9 # 10 # Output: build/hlasm_mini.o + build/hlasm_mini.log 11 12 -set -e 13 - 12 V=${1:-1} 13 14 BUILD_DIR=$(cd "$(dirname "$0")" && pwd) ... 31 -ferror-limit=100
32 "$SRC" 2>&1 | tee "$LOG" 33 36 -RC=$? 34 +# Use PIPESTATUS[0] to capture clang's exit code, not tee's. 35 +RC=${PIPESTATUS[0]:-$?} 36 echo "---" 38 -echo "rc=$RC obj=$OBJ log=$LOG" 37 +echo "compiler rc=$RC obj=$OBJ log=$LOG"

Called zos (ctrl+o to expand)

● Re-uploaded both. Try ./build_hlasm_mini.sh 1 again — the fresh upload may fix whatever the I/O error was, and the script's exit-code reporting now shows the real compiler rc.

✻ Churned for 2m 18s

❯ if you use zos_exec to run the build script, what do you see?

Called zos (ctrl+o to expand)

● Same EDC5122I I/O error as Joe saw. And the rc=0 is spurious — PIPESTATUS doesn't work under /bin/sh. Let me look at the local file for anything unusual.

● Bash(echo "=== local file bytes / encoding ==="; file /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c; wc -l -c /home/joede/git2026/zoweclang/zowe-common-…) ⎿  === local file bytes / encoding === /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c: C source, Unicode text, UTF-8 text 48 1485 /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c … +6 lines (ctrl+o to expand)

Called zos 2 times (ctrl+o to expand)

● Let me isolate whether it's upload-specific by creating a minimal file DIRECTLY on z/OS (not via upload) and compiling it.

Called zos 2 times (ctrl+o to expand)

● Upload-specific issue. Native-created file compiles fine; uploaded file can't be opened by ibm-clang64 despite looking normal. Let me compare the upload-created files against the native-created one at byte level.

Called zos (ctrl+o to expand) ⎿  API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.

TL;DR

The issue is likely due to a false positive detection of a usage policy violation by Claude Code, triggered by the upload and compilation of a C file containing embedded assembler code, and a potential workaround is to try switching to a different model, such as claude-sonnet-4-20250514, as suggested in the error message.

Guidance

• The error message suggests that the issue may be related to the usage policy, but the user believes it is a false positive, so it's worth investigating further.
• The user has already tried re-uploading the file and checking the local file for any unusual characters, but the issue persists.
• Switching to a different model, such as claude-sonnet-4-20250514, may resolve the issue, as suggested in the error message.
• The user may want to try to isolate the specific code or characters that are triggering the error and test them separately to see if they can reproduce the issue.
• It's also worth noting that the user has mentioned that this worked in a previous version (4.7), so it's possible that this is a regression issue.

Example

No specific code example is provided, but the user has included a link to the file they were working on: https://github.com/zowe/zowe-common-c/blob/v3.x/staging/c/recovery.c.

Notes

The issue is specific to the Opus model and the user is using version 2.1.119 of Claude Code. The user has already submitted a bug report to [email protected] and has a conversation ID of 215474044213289.

Recommendation

Apply workaround: try switching to a different model, such as claude-sonnet-4-20250514, as suggested in the error message, to see if it resolves the issue.