Trigger.dev has no "pull from environment" — the deployed state isn't recoverable as code, which makes overrides unavoidable on shared envs

Trigger.dev deploys are one-way: you can push local task code → an environment (dev / preview / staging / production), but there's no command to pull the deployed task source back out of an environment. That means the environment is not a recoverable source of truth — once code lands in staging, the only place that version exists as source is the git branch (or local machine) it was deployed from.

This breaks the standard git collaboration pattern:

pull → merge → push 

…because there's nothing to pull. If a teammate deploys a change to staging that I don't have locally, and the git branch they deployed from isn't shared (or they manually deployed from an unmerged branch), there is no way for me to retrieve that code. My next deploy silently overrides theirs — not because I chose to, but because I had no mechanism to discover and merge their work first.

What would fix this

A trigger pull <env> (or equivalent CLI / API) that materializes the currently-deployed task code as source files we can diff, merge, and re-push.

Thanks!