fix(calendar): creating and deleting calendar events works again

[davekilleen]

What was broken

Two Calendar MCP actions — creating an event and deleting an event — have been silently broken. The server runs its small helper scripts, but it ran every helper through Python, including the two that are written in bash (calendar_create_event.sh, calendar_delete_event.sh). Python can't read bash, so those two helpers failed instantly with a syntax error every single time. Asking Dex to put something on your calendar, or take something off it, could never succeed through this path.

Michelle found and reported this — she reproduced the exact failure, confirmed the scripts themselves are fine, and confirmed the same bug exists byte-for-byte on upstream main. Thank you, Michelle.

The fix

run_shell_script() in core/mcp/calendar_server.py now looks at the script's file type: .sh helpers run under bash, .py helpers keep the existing behavior (the venv interpreter with PYTHONPATH set, which the EventKit helpers need — unchanged from #63).

Verification

• Reproduced the reported failure first: running calendar_create_event.sh through Python fails with SyntaxError: invalid syntax at line 13, exactly as reported. Confirmed both .sh helpers pass bash -n.
• Added tests in core/tests/test_calendar_server.py:
  • .sh scripts dispatch to /bin/bash with args passed through
  • .py scripts still dispatch to sys.executable
  • every allowed .sh helper parses as valid bash
• Confirmed the new dispatch test fails on the previous code (expects /bin/bash, gets the Python interpreter) — it would have caught this bug.
• pytest core/tests/test_calendar_server.py: 10 passed (3 new, 7 pre-existing).
• ruff check core/: all checks passed.

Note: verified on Linux (test-level; the dispatch and bash-syntax checks are platform-independent). The end-to-end AppleScript path needs macOS and was not run here.

Proposed CHANGELOG entry (not committed — for the release that includes this)

Putting events on your calendar works again

Asking Dex to create or delete a calendar event quietly failed every time — the two helpers that do that work were being started the wrong way, so they crashed before they could begin. Thanks to Michelle for catching this and pinning down exactly where it broke.

What this fixes for you:

• Dex can create calendar events again. "Put a 30-minute hold on my calendar tomorrow at 10" now actually lands on your calendar instead of failing.
• Dex can delete calendar events again. Removing an event you asked Dex to clean up now works.
• This can't silently break again. A new automatic check makes sure each helper is always started the right way.

🤖 Generated with Claude Code

[github-actions]

What this pull request touches

• the task/meeting engine — feeds creating and updating tasks, processing meetings, and keeping that work connected.
• tests — feeds catching regressions before contributors and users encounter them.

Gates that will judge this change

• Personal-data gate: added lines must not expose real identities or personal vault content.
• Change-aware gates: source changes are checked for tests, path-contract use, documentation drift, and touched-file coverage.
• Tests and coverage: the Python, MCP, migration, hook, and script suites must remain healthy.
• Safety and quality: security, lint, distribution, path consistency, and large-vault checks still apply.

Based on 2 changed files.

[davekilleen]

CI triage note: the initial run's tests (3) failure was an unrelated flake, not this change.

• Failing test: core/tests/test_update_checker.py::test_failure_state_replaces_stale_release_status_and_same_day_skip_preserves_it (assert 'UNKNOWN' == 'offline' at line 928) — release-awareness update checker; this PR touches only the Calendar MCP script runner and its tests, with no shared code or state.
• The test's own helper (_verifier, test_update_checker.py:209-218) documents this exact failure mode: on a loaded CI runner, a git evidence subprocess can be killed/fail, surfacing as UNKNOWN instead of the expected status — "making these tests non-hermetic and order-dependent." The generous 3600s budget mitigates the deadline path but not subprocess failures under load.
• The test passes locally on this branch, both in isolation and with -n auto --dist loadgroup (55/55 in the file).
• Same shard on the same commit passed on rerun with zero code changes — full CI is now green (tests 1/2/3, quality, test-results all pass).
• Recent main also shows runner noise in this suite (run 31094475720's tests (2) failed with "hosted runner lost communication").

If this test flakes again, the durable fix belongs in the update-checker test fixtures (hermetic git-runner injection for the pre-fetch evidence path), not in retries.

🤖 Generated with Claude Code