[BUG] docx/pptx/xlsx skills: soffice.py raises "module 'socket' has no attribute 'AF_UNIX'" on Windows (re-filing #78841, closed as stale)

Preflight Checklist

• [x] I have searched existing issues. This exact bug has been reported twice and both reports were closed by the stale bot with no human triage: #78841 (opened 2026-07-18, closed 2026-09-04 as NOT_PLANNED) and #35063 (opened 2026-03-16, closed 2026-04-13, now locked). Re-filing a fresh issue as the closing bot instructs.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

Environment

• Windows 11 Pro, build 26300
• Claude Desktop 2.110.0.0 (MSIX), Claude Code 2.1.272 — failure happens in the desktop app's Code tab
• Python 3.14.7 (python.org installer) and 3.14.5 (Python Install Manager)
• LibreOffice is not installed on this machine, by policy
• Skills come from the account channel: the desktop app syncs the account's enabled skills and passes them to every Code session (%LOCALAPPDATA%\Claude\logs\main.log: [SkillsPlugin] Found 9 enabled skills, [CCD] Using skills plugin at: ...\skills-plugin\..., [CCD] Passing 1 plugin(s) to SDK (skills: 1, remote: 0, local: 0))

What's wrong

On 2026-09-15 a Claude Code session used anthropic-skills:docx and ran the command the skill's SKILL.md prescribes:

python <skills>/docx/scripts/office/soffice.py --headless --convert-to pdf output.docx

It failed with module 'socket' has no attribute 'AF_UNIX'.

The root cause is exactly the one already documented in #78841: scripts/office/soffice.py → _needs_shim() calls socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) inside a try / except OSError. On Windows socket.AF_UNIX does not exist as an attribute, so the call raises AttributeError, which that except does not catch; it propagates as the generic "Could not prepare the LibreOffice environment". The fallback path it would otherwise take is Linux-only anyway (gcc -shared -fPIC ... -ldl, loaded through LD_PRELOAD).

Two things make this more than a single skill bug:

1. Installing LibreOffice does not help. The reporter of #78841 had LibreOffice installed and working and still hit the failure, because the crash happens before LibreOffice is ever invoked.
2. Windows users cannot opt out of the broken path. The built-in Office skills (Word, PowerPoint, Excel, PDF) are not listed individually in Customize > Skills — they follow the "Code execution and file creation" capability — and that capability toggle has no effect on Claude Code sessions: I turned it off, fully restarted the desktop app, and both a resumed session and a brand-new session still received anthropic-skills:docx, pptx and xlsx in their skill listing. skillOverrides is documented as not applying to plugin skills, and the account bundle does not appear in /plugin. So on Windows the failing skills are always offered and cannot be disabled one by one.

Scripts affected on this machine (all three skills ship the same helper): docx/scripts/office/soffice.py, docx/scripts/accept_changes.py, pptx/scripts/office/soffice.py, pptx/scripts/thumbnail.py, xlsx/scripts/office/soffice.py, xlsx/scripts/recalc.py.

Steps to reproduce

1. On Windows, with the account's document skills enabled, open a Claude Code session in the desktop app.
2. Ask for a .docx → PDF conversion, or for tracked changes to be accepted in a .docx.
3. The session follows the skill and runs python .../scripts/office/soffice.py --headless --convert-to pdf x.docx.
4. It returns {"error": "Could not prepare the LibreOffice environment: module 'socket' has no attribute 'AF_UNIX'"} — with or without LibreOffice installed.

What should happen

• _needs_shim() should not assume socket.AF_UNIX exists: use getattr(socket, "AF_UNIX", None) or an explicit platform check, and catch AttributeError alongside OSError.
• On Windows the skill should use a conversion path that exists on the platform, or fail with an actionable message naming the real cause, instead of a generic "could not prepare the environment".
• Separately, and the reason this keeps biting Windows users: the built-in Office skills should be disableable individually, or at least follow a switch that applies to Claude Code sessions.

Same class of problem, still open

#91090 — the docx skill's XSD validator opens OOXML parts with no encoding argument, so on Windows it decodes UTF-8 content with the local code page and raises UnicodeDecodeError. Same underlying assumption: the skills are written for the Linux sandbox and run unmodified on Windows.

Workaround in use

A PreToolUse hook (matcher Bash|PowerShell) that blocks execution of soffice.py, accept_changes.py, recalc.py, thumbnail.py and the soffice binary, and returns a message telling the model to use Word, PowerPoint or Excel through COM automation instead. It does not fix the skills — it stops the failing path and redirects it.