obsidian-to-x

The package and documentation implement a functional automation workflow that intentionally evades X anti-automation by using OS-level paste events and reusing persistent browser sessions. There is no explicit evidence in the provided fragment of direct malware (no obfuscated payloads, no outbound exfiltration endpoints, no reverse shell). However, the design is high-risk: it grants powerful local GUI control via Accessibility permissions and enables actions under the user's authenticated browser session, which can be abused if the code or environment is compromised. Treat this as a moderate-to-high operational risk: acceptable only with strict controls (trusted code, isolated profile/machine, audited environment).

The skill footprint aligns reasonably with its stated purpose of publishing Obsidian content to X/Twitter via a real Chrome browser, including support for both regular posts and X Articles with frontmatter-driven decisions. Core data flows stay within local content and browser automation, reducing server-side exposure. The main security considerations concern the use of browser-based automation to bypass anti-bot measures (potential misuse risk) and the handling of content visible in or captured by the automated browser session. Overall, the evaluation yields a benign-to-suspicious profile: the capability is coherent with the stated purpose, but the explicit bypass of anti-bot detection and browser-based posting introduce a moderate risk surface that warrants careful use and explicit user consent for content visibility in automated browser sessions.