Thanks a lot for the thoughtful comment, I really appreciate it. You are absolutely right that screen and tmux use separate PTYs for sessions, and they are bot

Thanks a lot for the thoughtful comment, I really appreciate it. You are absolutely right that screen and tmux use separate PTYs for sessions, and they are both extremely powerful. I actually use screen myself and it was one of the main inspirations for sbsh. The main difference is that sbsh provides manifests to define terminal sessions declaratively. A manifest can include commands, environment variables, prompts, and lifecycle hooks such as onInit and postAttach. This makes it easy to reproduce and share terminal configurations, for example to run the same process locally or inside a CI/CD pipeline without manual setup. Unlike screen, sbsh includes session discovery and metadata. It keeps a metadata directory that stores detailed information about all running terminals and supervisors, including their profiles and states. This allows you to query or reattach programmatically through the API. Regarding configuration management, I agree that Ansible is great for provisioning and automation, but my goal with sbsh was different. I wanted a lightweight tool to set up working environments for Terraform, Kubernetes, Python venvs, and similar workflows. For large Terraform projects with many environment variables, keeping local runs consistent can be difficult. sbsh profiles help with that by defining everything once and setting up a clear prompt to avoid running commands in the wrong environment. The same applies to Kubernetes clusters with multiple environments and namespaces. You can also share these manifests with teammates so that when they start a terminal session, the environment is configured exactly the same way, with the right variables, cluster context, and visual prompt. This ensures consistency and prevents human error across local and CI/CD environments. In short, sbsh focuses on developer session reproducibility rather than system configuration. It fills the gap between shell setup, automation, and environment safety. Thanks again for the feedback. I completely agree that adopting new tools is always a challenge, but I built this to solve my own workflow pain, and it has made a big difference for me.