Add opencode-handoff-p2p skill (Collaboration & Project Management)

[Eldorado-ling]

What this PR adds

A new skill: opencode-handoff-p2p under "Collaboration & Project Management".

Real use case

OpenCode users frequently want to transfer the current session's context to:

• A collaborator (to let them continue your work)
• Another machine of their own (laptop → workstation)
• A future session (to avoid context loss between sessions)

The current pattern is /share → copy URL → paste into WeChat/Slack/email → recipient opens it → manually relays context to their agent. High friction, easily lost, URLs scattered across chat history.

This skill replaces that with: user says "send to bob" → agent automatically verifies, signs, and pushes to bob's private GitHub inbox repo. Bob's next session: "check inbox" → agent pulls, runs 5-tier verification, fetches transcript, injects into current session.

What's included

• SKILL.md — the protocol the agent reads (~440 lines)
• verify_inbox.py — reference verification script (~290 lines Python)
• README.md — pointer to full deployment guide in main repo

Tested with OpenCode

Production-tested end-to-end with DeepSeek V4 Pro on Windows + Git Bash. Specifically validated:

• Tier 5 GPG signature verification (GitHub returns verified: true for properly signed commits)
• Transactional fetch-before-delete (URL fetch failure preserves inbox file for retry)
• CRLF tolerance (URL regex accepts \r?\n terminator for cross-platform robustness)
• Trust boundary preamble (downstream agents respect the third-party-data marker)

Safety

• Built-in confirmation step before any send
• Tier 4 catches sender impersonation (commit author+committer must match claimed sender)
• Tier 5 requires GPG signature when require_signed_commits: true
• Trust boundary preamble prevents autonomous execution of share content
• AGENTS.md hard rule forbids handoff-content-triggered local writes
• Reference Python implementation prevents shell interpretation drift

Main repo

https://github.com/Eldorado-ling/opencode-handoff-p2p

Includes full INSTALL.md (minimal + hardened deployment paths), USAGE.md (daily workflow + 11 error scenarios), 3-round security audit results, MIT license.

Comparison with combined variant

There's also https://github.com/Eldorado-ling/opencode-handoff-skill which bundles shared-central-repo mode + P2P. This PR submits only the P2P-only variant which has the smallest attack surface and simplest config — recommended for individual users and small (≤5 people) trust groups.

[gemini-code-assist]

Code Review

This pull request introduces the opencode-handoff-p2p skill, which enables peer-to-peer transfer of OpenCode session share URLs via private GitHub inbox repositories, supported by a reference Python verification script. The review feedback identifies a critical security vulnerability in the verification script where checking only the original adding commit allows attribution and signature bypasses on modified files; updating this to check the last modifying commit is recommended. Additionally, the feedback suggests allowing the SSH protocol in git clone configurations to prevent failures for users with SSH-default GitHub CLI setups.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Critical Security Vulnerability: Attribution & Signature Bypass via File Modification

Using git log --diff-filter=A retrieves the commit that originally added the file. If a collaborator (or an attacker with write access) modifies an existing handoff file rather than creating a new one, get_add_sha will still return the original commit SHA.

Consequently:

1. Tier 4 (author/committer check) and Tier 5 (GPG signature check) will run against the original, trusted commit.
2. The modified, untrusted content (containing a potentially malicious URL) currently at HEAD will be fetched and executed/displayed.

This completely bypasses the signature and attribution verification.

Solution

Query the last commit that modified the file instead of the adding commit. This ensures that the commit responsible for the current file content is the one being verified.

Rename this function to get_last_commit_sha and use git log -1:

Suggested change

	def get_add_sha(clone: Path, filepath: str) -> Optional[str]:
	rc, out, _ = run([
	"git", "-C", str(clone),
	"log", "--diff-filter=A", "--format=%H", "--", filepath,
	])
	if rc != 0:
	return None
	lines = [l for l in out.decode("utf-8", "replace").splitlines() if l]
	return lines[0] if lines else None
	def get_last_commit_sha(clone: Path, filepath: str) -> Optional[str]:
	rc, out, _ = run([
	"git", "-C", str(clone),
	"log", "-1", "--format=%H", "--", filepath,
	])
	if rc != 0:
	return None
	lines = [l for l in out.decode("utf-8", "replace").splitlines() if l]
	return lines[0] if lines else None

[gemini-code-assist]

Update the call site to use get_last_commit_sha instead of get_add_sha to match the security fix.

Suggested change

	sha = get_add_sha(clone, filename)
	sha = get_last_commit_sha(clone, filename)

[gemini-code-assist]

Usability Issue: SSH Protocol Blocked for GitHub CLI Clones

Many developers configure the GitHub CLI (gh) to use SSH by default (gh config set git_protocol ssh).

By setting protocol.allow=never and only allowing protocol.https.allow=always, any SSH-based clone attempt will fail with fatal: transport 'ssh' not allowed.

To support both HTTPS and SSH configurations seamlessly while maintaining hardening against other protocols (like file://), you should also explicitly allow the ssh protocol.

Suggested change

	gh repo clone "$ME/$REPO_NAME" <path> -- \
	-c core.symlinks=false \
	-c protocol.file.allow=never \
	-c protocol.allow=never \
	-c protocol.https.allow=always \
	-c submodule.recurse=false
	gh repo clone "$ME/$REPO_NAME" <path> -- \
	-c core.symlinks=false \
	-c protocol.file.allow=never \
	-c protocol.allow=never \
	-c protocol.https.allow=always \
	-c protocol.ssh.allow=always \
	-c submodule.recurse=false

[gemini-code-assist]

Explicitly allow the ssh protocol in the local git configuration to support SSH-based clones.

Suggested change

	git -C <clone-path> config --local core.symlinks false
	git -C <clone-path> config --local submodule.recurse false
	git -C <clone-path> config --local protocol.allow never
	git -C <clone-path> config --local protocol.https.allow always
	git -C <clone-path> config --local protocol.file.allow never
	git -C <clone-path> config --local core.symlinks false
	git -C <clone-path> config --local submodule.recurse false
	git -C <clone-path> config --local protocol.allow never
	git -C <clone-path> config --local protocol.https.allow always
	git -C <clone-path> config --local protocol.ssh.allow always
	git -C <clone-path> config --local protocol.file.allow never

[gemini-code-assist]

Allow the ssh protocol during recipient repository cloning to support SSH-based GitHub CLI configurations.

Suggested change

	gh repo clone "<recipient>/$REPO_NAME" "$tmpdir" -- \
	-c core.symlinks=false -c protocol.file.allow=never \
	-c protocol.allow=never -c protocol.https.allow=always \
	-c submodule.recurse=false
	gh repo clone "<recipient>/$REPO_NAME" "$tmpdir" -- \
	-c core.symlinks=false -c protocol.file.allow=never \
	-c protocol.allow=never -c protocol.https.allow=always \
	-c protocol.ssh.allow=always \
	-c submodule.recurse=false

[Eldorado-ling]

@gemini-code-assist Thanks for the review! Both issues are fixed in this update:

✅ Tier 4/5 identity bypass (CRITICAL)

Renamed get_add_sha → get_last_modifying_sha and switched from git log --diff-filter=A to git log -1. Now Tier 4 verifies the commit that produced the current blob (which is what Tier 3 actually inspects), not just the original add. This closes the bypass where a collaborator could modify a file added by a trusted sender.

Tested locally with simulated attack: alice signs+pushes a legitimate handoff → mallory modifies it locally → verify script correctly flags Tier 4 failure with commit_sha pointing to the modification commit, author_login: null (since mallory's commit isn't on GitHub), action: keep. Defense holds.

✅ SSH protocol allow

Added -c protocol.ssh.allow=always alongside the existing -c protocol.https.allow=always in all 4 clone hardening sites (bootstrap example + bootstrap clone + send tmpdir clone). Both protocols now explicitly allowed; everything else (file://, git://) still blocked.

Main repo updated to v1.0.1

https://github.com/Eldorado-ling/opencode-handoff-p2p/releases/tag/v1.0.1 — signed commit (verified), signed tag.

Same fixes also applied to the bundled (shared + P2P) variant at https://github.com/Eldorado-ling/opencode-handoff-skill v1.0.1 (not part of this PR).

[gemini-code-assist]

Thanks for the update, @Eldorado-ling. The changes look solid. Switching to git log -1 for Tier 4 verification correctly addresses the identity bypass by ensuring we validate the commit that actually produced the current file content, rather than just the initial addition. Adding protocol.ssh.allow=always is also the right move for broader compatibility with different Git configurations. These fixes significantly strengthen the security model of the opencode-handoff-p2p skill.