fix(cli): enforce utf-8 encoding for screenshot text outputs

[Aj2280]

Summary

In sdks/python-cli/omi_cli/commands/local.py, _write_screenshot_result() invoked Path.write_text() without specifying encoding="utf-8". On Windows locales using legacy non-UTF-8 default encodings (e.g. cp1252), saving plain-text OCR or metadata containing multilingual characters (e.g. Screenshot OCR: café 東京) fails with UnicodeEncodeError.

This PR explicitly sets encoding="utf-8" on all output.write_text() calls in _write_screenshot_result(), ensuring reliable UTF-8 screenshot text exports across all platforms and locale settings.

Fixes #13072

Changes

• sdks/python-cli/omi_cli/commands/local.py:
  • Specified encoding="utf-8" for string outputs, dictionary content outputs, and JSON fallback outputs in _write_screenshot_result().
• sdks/python-cli/tests/test_local_screenshot_encoding.py:
  • Added unit and CLI command tests verifying UTF-8 encoding behavior for plain strings, content mappings, and JSON fallback payloads when non-UTF-8 preferred encodings (e.g. cp1252) are simulated.

Verification

• Automated Tests:
  • sdks/python-cli/venv/bin/pytest sdks/python-cli/tests/test_local_screenshot_encoding.py -v: 4/4 passed.
  • sdks/python-cli/venv/bin/pytest sdks/python-cli/tests/: 132 passed, 1 skipped.
• Manifest Preflight:
  • Validated with scripts/pr-preflight.

Failure-Class: none

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[Git-on-my-level]

Thanks @Aj2280 — clean, well-scoped fix for #13072, and the tests are the right shape for it.

What I verified:

• sdks/python-cli/omi_cli/commands/local.py: _write_screenshot_result() had exactly three text-writing calls relying on the locale-dependent default encoding — the plain-string path, the mapping content path, and the final JSON fallback. All three now pin encoding="utf-8". The binary paths are correctly left alone: shutil.copyfile(...) for file-backed results and output.write_bytes(...) for base64 payloads never go through text encoding.
• sdks/python-cli/tests/test_local_screenshot_encoding.py: covers all three text paths at the unit level plus one end-to-end omi --json local screenshot 9 --output ... run against a mocked local API, reusing the existing test_local.py helpers and conftest.py fixtures (all of which resolve at this head). I also confirmed the locale.getpreferredencoding patch is a genuine seam: with UTF-8 mode off, Path.write_text() without encoding= resolves its codec through exactly that function, so the pre-fix code reproduces the reported UnicodeEncodeError under a simulated legacy code page and the pinned version does not. The fix and its regression tests are real, not vacuous.

One non-blocking note: on interpreters running with UTF-8 mode enabled (PYTHONUTF8=1, or newer interpreters where it is the default), open() ignores the preferred locale encoding, so these particular tests would pass even without the fix on such machines. They still discriminate correctly on the Windows locales from the issue, which is what matters — just worth knowing the red/green signal depends on UTF-8 mode being off.

Good first contribution. This feedback is AI-generated on behalf of the Omi maintainers; leaving the merge decision to a human maintainer.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[kodjima33]

fix(cli): enforce utf-8 encoding for screenshot text outputs. Confidence 5/5 (root cause stated, fixes #13072, tiny scoped diff, regression tests added). Confirmed bug still present on main (write_text calls in local.py lack encoding param).