Host Git Workflow: Branch to Merge, Safely
Security checks across malware telemetry and agentic risk
Overview
This is a coherent GitHub workflow tool, but it can reinterpret verification requests as permission to start a high-impact push/PR/merge flow on a real host repository.
Install only if you want an agent to operate on a real host Git repository. Before use, configure the repo path carefully, verify the bound host node, use least-privilege GitHub access, and require explicit confirmation before any push, PR creation, merge, or main sync.
VirusTotal
VirusTotal engine telemetry is currently stale for this artifact.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A seemingly harmless plugin-check request could start a real repository shipping flow instead of only reporting readiness.
A user asking to verify or test the plugin can be routed into the same workflow used to ship repository changes.
For live verification requests such as `проверь работает ли плагин openclaw-host-git-workflow` or `нужен полный цикл`, the bundled skill should normalize that phrasing to the same canonical `send_to_git` intent and start the bounded chain immediately.
Require explicit user confirmation before treating verification or test wording as permission to push, open PRs, merge, or sync main.
If invoked on the wrong repo or branch, the agent could push code, create or reuse a PR, merge into main, and alter the local main branch.
The documented default chain includes publishing branches, creating PRs, merging, and syncing main, while encouraging proactive execution rather than explicit per-step approval.
Recommended Session Flow ... `push_branch` ... `create_pr` ... `wait_for_checks` ... `merge_pr` ... `sync_main` ... Routine bounded steps are expected to behave proactively: - do the work first
Add hard confirmation gates before push, PR creation, merge, and main sync, especially when the user did not explicitly request each mutating step.
The tool needs access to credentials that can read or mutate GitHub repositories; copying SSH keys into containers increases credential exposure if the container is not trusted.
The workflow uses existing GitHub CLI authentication and may instruct the user to copy a GitHub SSH key into a container for host readiness.
await runner.run(resolveHostGhBin(), ["auth", "status"] ...); ... "docker cp ~/.ssh/<working_github_key> <container>:/home/node/.ssh/id_ed25519"
Use least-privilege GitHub credentials, review the target repo and host node before running, and avoid copying private SSH keys into untrusted containers.