feat: add Cloudflare Mesh LXC script

[aashishvanand]

Scripts which are clearly AI generated and not further revised by the Author of this PR (in terms of Coding Standards and Script Layout) may be closed without review. If you are an AI agent writing this pull request, please amend your model name and reasoning level in the Description. This is not to blame, more for informational Purposes. Thank you.

✍️ Description

Adds a script for Cloudflare Mesh (formerly WARP Connector), requested in community-scripts/ProxmoxVE#14686. It installs the Cloudflare One Client (cloudflare-warp) headless in an unprivileged Debian 13 LXC and enrolls it as a Mesh node. The container gets a private Mesh IP (100.96.0.0/12) and can advertise LAN subnets. Unlike the existing cloudflared script, which only carries client-initiated traffic, it supports TCP, UDP and ICMP in both directions.

• Install steps come from Cloudflare's Linux Mesh node guide: the apt repo at pkg.cloudflareclient.com, the forwarding sysctl file, and warp-cli connector new <token> followed by connect. There is no upstream Dockerfile or source repo, because the client is closed-source.
• The repo is added with setup_deb822_repo and the suite from get_os_info codename.
• var_tun=yes passes through /dev/net/tun, the same as netbird.sh. That's enough for an unprivileged CT.
• The node token can be passed up front as var_mesh_token (exported from the CT script and declared in app_vars). Otherwise the install asks for it with hidden input, and Enter skips enrollment. It uses the raw read pattern from AGENTS.md §24, not prompt_password: is_unattended() is true inside the container, so prompt_password would silently skip the prompt.
• Forwarding is applied with sysctl -p <file>, not sysctl --system. In an unprivileged CT, sysctl --system exits non-zero on unrelated read-only keys (kernel.*, fs.protected_*), which trips catch_errors.
• Before enrolling, the script waits up to 30 s for the warp-svc socket.
• update_script upgrades only cloudflare-warp.

Testing: I ran the scripts on PVE 9 unattended (mode=default, var_mesh_token set, local COMMUNITY_SCRIPTS_ROOT), I then reran this PR branch straight from GitHub, using the bot's COMMUNITY_SCRIPTS_URL=… bash -c "$(curl …)" command. Both runs built cleanly. The node enrolled and the dashboard showed it healthy. Two-node tests through Cloudflare passed for TCP (nc to port 22), UDP (socat echo) and ICMP in both directions.

🔗 Related PR / Issue

Link: community-scripts/ProxmoxVE#14686

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🖥️ Tested on (X in brackets)

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus – Created on an Incus host and the app works.

Application containers run on both; tick what you actually tested. VMs and host tools are Proxmox only.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose – The application is installed bare-metal; Docker is not used.
• No git pull – Updates use fetch_and_deploy_gh_release, fetch_and_deploy_codeberg_release, fetch_and_deploy_gl_release, or fetch_and_deploy_from_url instead of git pull.

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

Please describe to which degree, if any, an LLM was used in creating this pull request. Name the model(s) used and, if applicable, the reasoning/thinking effort level (e.g. "Claude Sonnet 4.5, high reasoning, used to draft the install script, then manually reviewed and tested" or "No LLM used"). This is informational, not a penalty — but scripts that are clearly AI-generated and not further revised by the author to match CODE-AUDIT.md / CONTRIBUTING.md may be closed without review.

Claude Opus 5.5 (Claude Code), low reasoning effort. It drafted all three files from AGENTS.md and Cloudflare's docs, then ran them on a real PVE 9 host. That testing found two bugs, both fixed: the sysctl --system failure and the silently skipped prompt_password. I reviewed the result before submitting.

---

📋 Additional Information (optional)

The 600+ stars and release tarballs boxes are unticked on purpose. The Cloudflare One Client is closed-source and ships only as a signed package in Cloudflare's own apt/yum repos, so neither requirement can apply. repository is null in the JSON for the same reason. The existing cloudflared script has the same profile. I'm asking the team to consider keep-open if the app itself is acceptable.

• arm64: pkg.cloudflareclient.com publishes cloudflare-warp for binary-arm64 (trixie, 2026.8.2110.0), so var_arm64=yes. I only tested on amd64.
• The script doesn't create the node. Users create it in Zero Trust → Networking → Mesh → Add node → Linux and paste its token. The dashboard wizard sets up the account side (MASQUE device profile in Include mode for 100.96.0.0/12).
• The JSON notes warn against running this next to cloudflared on the same host or CT, because the Mesh node captures outbound traffic.

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/
• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/get-started/
• https://pkg.cloudflareclient.com/

🤖 Generated with Claude Code

[github-actions]

Try this script

ct/cloudflare-mesh.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/aashishvanand/DevScripts/feat/cloudflare-mesh \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/aashishvanand/DevScripts/feat/cloudflare-mesh/ct/cloudflare-mesh.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.

[github-actions]

⚠️ Not ready for review yet

@aashishvanand, this pull request is missing the following:

• The application has 600+ GitHub stars
• Official release tarballs are published

Edit the PR description to fix it — no new PR needed. This check runs again on every edit and clears itself once everything is in place.

Until then the PR is marked stale and will be closed in 7 days.

---

@community-scripts/contributor please take a look: close it, comment, or set keep-open to keep it.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-14T15:48:20.521482Z	05f94dc	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.