feat(daemon): add remote messaging control

[rmacomber]

Summary

• add opt-in Telegram and WhatsApp remote control for vixd
• require explicit feature/config enablement plus sender allowlists before accepting remote prompts
• run remote prompts in isolated headless sessions and deny unattended permission/plan interactions
• document remote-control configuration in the README

PR cleanliness

• Based on upstream/main at c25f0d73ecc7ab55a540892c8c061ea8b725fc15
• Contains one feature commit: b730897 feat(daemon): add remote messaging control
• Does not include PR feat(config): add code-explorer default agent #38 (21afebd73e86a4bc157796e39076ae0cf456a09e is not an ancestor)
• Does not include PR feat(config): add code-explorer default agent #38's file: internal/config/defaults/agents/code-explorer.md

Verification

• gofmt check passed for changed Go files
• go build ./cmd/vix ./cmd/vixd
• go test ./cmd/vixd ./internal/config
• go test ./internal/daemon -run 'Test(AuthorizedRemoteIDRequiresAllowlist|RemoteSessionOptionsDisableAutomaticPermissions|RemoteUnattendedEventsDoNotAutoApprove|TelegramSendMessageRedactsBotTokenFromErrors|WhatsAppStartFailsWhenWebhookAddrAlreadyBound|TelegramSendMessagePostsChatIDAndText|TelegramGetUpdatesRedactsBotTokenFromErrors|WhatsAppWebhookVerificationAndAllowlist)'
• go test ./cmd/vix ./cmd/vixd ./internal/agent ./internal/auth ./internal/config

Note: full go test ./... currently fails in pre-existing internal/daemon tests unrelated to this branch: missing testdata/tmp.go fixture expectations in VFS/minify tests and Landlock sandbox environment assumptions. The changed remote-control tests pass.

[kirby88]

Thanks so much for this, really nice work and clearly a lot of thought went into it. I'd love to get it merged. There are a handful of things I'd like to see addressed first:

• Tests. There's no e2e scenario yet, and our CONTRIBUTING guide asks for one on daemon/session behavior changes like this, so could you add one under e2e/scenarios/? The unit tests cover the leaf helpers well, but the core runRemotePrompt event loop is untested. I'd like coverage on the deny-on-confirm path and the error-on-question/plan paths in particular.

• Document the real threat model in the README. "Denies unattended permissions" reads like a sandbox guarantee, but because $HOME and cwd are auto-allowed by our default access policy, an allowlisted sender effectively gets in-cwd shell plus read/write across $HOME, with output streamed straight back to their chat. That's a real exfiltration channel, so I'd like it spelled out: recommend a locked-down cwd, suggest deny-listing sensitive paths (~/.ssh, ~/.aws, etc.), and note that compromise of an allowlisted account or the bot token means host access.

• De-dupe against runJob. runRemotePrompt is essentially a fork of the job runner, down to a copy of the generic event decoder. I'd rather not have two copies of our most safety-sensitive loop drifting apart over time. Could you extract the shared "isolated headless run + harvest result" core and have both call it with their own unattended-event policy?

• Add a concurrency cap or rate limit on inbound messages. Right now every message spawns a full agent session with no ceiling, so a compromised allowlisted account could flood us.

• A few smaller cleanups: drop the remoteSessionAutomaticPermissions no-op (or make it a real policy), update the TriggerInfo doc comment now that there's a third trigger type, document or remove the workflow config field, and make the WhatsApp Graph API version configurable rather than hardcoded.

Happy to talk through any of these, especially the de-dup if you want to sketch the shape before diving in. Thanks again for the contribution, looking forward to it.

[rmacomber]

Picking this back up now. I’ll update the PR around the review items rather than leaving it stale:

• add e2e coverage for the unattended remote-control session paths
• document the actual security model and recommended locked-down config
• de-duplicate the isolated headless run loop with the job runner
• add an inbound concurrency/rate limit
• clean up the config/docs nits called out above

I’ll push a revision once those are addressed.

[rmacomber]

Pushed a follow-up revision addressing the review items:

• added a shared unattended session runner and moved jobs + remote prompts onto it
• kept remote-control confirmation requests denied, and questions/plans fail closed
• added max_concurrent_runs with a busy reply for excess inbound messages
• made WhatsApp Graph API version configurable
• documented the remote-control threat model, workflow config, and recommended locked-down setup
• added a staged e2e acceptance scenario for remote-control policy; it is skipped for now because the harness does not yet expose provider ingress/reply injection

Validation run locally:

GOCACHE=/tmp/vix-go-cache go test ./internal/daemon -run 'TestRemote|TestWhatsApp|TestTelegram|TestJobRunResultFromUnattended|Test.*RunNow|Test.*Trigger' -count=1 -v
GOCACHE=/tmp/vix-go-cache go test ./internal/config ./internal/protocol -count=1 -v
cd e2e && GOCACHE=/tmp/vix-go-cache go test ./scenarios -run TestRemoteControlUnattendedPolicyAcceptance -count=1 -v