OSC 7501: Protokol Status Program agar Terminal Tahu Sedang Apa

OSC 7501 adalah escape sequence terminal baru yang memungkinkan program melaporkan sendiri statusnya: idle, working, blocked, done, atau error, lengkap dengan alasannya. Spesifikasinya ditulis Mitchell Hashimoto dan dipublikasikan 6 Oktober 2026, lahir dari pekerjaannya di Superlogical dan emulator terminal Ghostty. Idenya sederhana tapi mendasar: program sudah tahu apa yang sedang dilakukannya, jadi tidak perlu ada pihak lain yang menebak dari layar atau daftar proses.

TL;DR

• Formatnya daftar pasangan key=value yang dipisah titik dua, dikirim lewat pty yang sudah selalu tersedia.
• Hanya satu kunci yang wajib: state, dengan nilai idle, working, done, blocked, atau error.
• Kunci opsional mencakup app untuk nama program dan msg untuk pesan satu baris berformat base64.
• Program yang menjalankan banyak tugas bisa melaporkan beberapa record sekaligus lewat id hierarkis.
• Terminal yang tidak mengenal OSC ini akan mengabaikannya, jadi aman dikirim ke mana saja.

Masalah apa yang sebenarnya ingin diselesaikan OSC 7501?

Pekerjaan berdurasi panjang di terminal sudah jadi hal biasa: build, deployment, upgrade paket, pemrosesan data, dan makin sering, coding agent. Program-program ini bergantian antara bekerja sendiri, menunggu pengguna, dan selesai. Masalahnya, pengguna biasanya berpindah mengerjakan hal lain dan hanya ingin tahu kapan pekerjaan itu selesai atau kapan mereka dibutuhkan.

Selama beberapa dekade, aspek masalah ini sudah dijawab dengan cara berbeda-beda. Sebagian terminal memantau proses foreground yang aktif dan memberi notifikasi saat berubah. Cara lain menunggu periode keluaran yang sepi selama jangka waktu tertentu. Menurut penulisnya, tidak ada solusi yang kohesif, netral terhadap jenis interaksi, dan generik, yang sekaligus menyampaikan progres, kondisi terblokir, penyelesaian, dan pohon tugas.

Kenapa pendekatan heuristik dianggap tidak cukup?

Karena heuristik menebak, bukan melaporkan. Contoh yang dikutip adalah Herdr, salah satu alat yang oleh penulisnya justru digambarkan melakukannya dengan baik dan terbuka. Herdr punya detection manifests berupa aturan TOML yang mengklasifikasikan sebuah agent sebagai idle, working, atau blocked. Untuk satu agent saja, ada 16 aturan, dan salah satunya menandai status working bila judul jendela dimulai dengan karakter spinner Braille atau setengah lingkaran sejak versi 2.1.228.

Riwayat berkas aturan itu menunjukkan sepuluh perubahan dalam tiga bulan hanya untuk satu program. Ini bukan kritik terhadap Herdr, melainkan ilustrasi biaya dari pendekatan menebak: setiap perubahan kecil pada tampilan program memaksa aturan deteksi ikut diperbarui. Kalau programnya sendiri yang melapor, seluruh kelas kerapuhan ini hilang.

Bagaimana bentuk protokolnya?

Isi sequence adalah daftar pasangan key=value yang dipisahkan karakter titik dua, dan kunci yang wajib hanyalah state. Nilai state ada lima: idle berarti diam menunggu instruksi berikutnya, working berarti sedang berjalan dan boleh menyertakan persentase progres, done berarti selesai dengan hasil siap tapi belum dilihat pengguna, blocked berarti tidak bisa lanjut sampai pengguna melakukan sesuatu, dan error berarti gagal lalu berhenti.

Untuk kondisi blocked, ada kunci kind yang menjelaskan jenis hambatannya, yaitu permission, question, atau auth, sementara kunci msg menjelaskan alasannya. Kunci opsional lain mencakup app, yaitu nama program yang stabil dan terbaca mesin seperti cargo atau claude-code, serta msg berupa satu baris teks untuk manusia yang dienkode base64. Ada juga state clear yang menghapus record.

State	Arti
idle	Diam, menunggu instruksi berikutnya dari pengguna
working	Sedang berjalan, boleh menyertakan persentase progres
done	Selesai, hasil siap dan belum dilihat pengguna
blocked	Tidak bisa lanjut sampai pengguna bertindak, dijelaskan lewat kind dan msg
error	Gagal lalu berhenti

Bagaimana program yang menjalankan banyak tugas sekaligus melapor?

Dengan id hierarkis. Sebuah alat deployment bisa berstatus working di akar, sementara cabang us-east sedang mengunggah image di 40 persen dan cabang eu-west berstatus blocked menunggu persetujuan rilis ke produksi. Kedua kondisi itu benar pada saat yang sama, dan terminal yang memutuskan bagaimana menampilkannya. Model ini membuat status bersifat seperti pohon, bukan satu nilai tunggal yang saling menimpa.

Contoh integrasi di spesifikasi bahkan hanya berupa satu fungsi shell pendek yang mencetak sequence ke stdout, lalu dipakai membungkus perintah seperti rsync. Tidak ada SDK, tidak ada socket, tidak ada variabel lingkungan, dan tidak ada JSON. Penulisnya menegaskan ini bisa ditulis dengan POSIX sh biasa, tanpa bias ke presentasi GUI tertentu maupun ke jenis beban kerja tertentu seperti AI.

Sudah ada implementasinya?

Sudah, dan penulisnya mengklaim menulis protokol ini dua kali: satu implementasi di libghostty dan satu lagi di Rex. Selain itu ada proof-of-concept di Terraform, salah satu coding agent, Codex, dan Homebrew, baik lewat plugin maupun fork. Dalam setiap kasus, menurutnya implementasinya tidak lebih dari selusin baris kode. Angka itu masuk akal karena protokolnya memang dirancang untuk mudah dipancarkan aplikasi dan mudah diurai emulator terminal.

Yang membuat protokol ini punya peluang diadopsi luas adalah sifatnya yang tidak merusak. Terminal yang tidak mengenali OSC ini akan mengabaikannya, jadi program bisa mengirimkannya tanpa perlu memeriksa dukungan lebih dulu, meskipun spesifikasi tetap menyediakan mekanisme feature detection dan terminfo bagi yang ingin lebih hati-hati.

Kenapa lewat pty lebih baik daripada socket atau API khusus?

Karena pty sudah selalu ada di jalur yang sama dengan program yang berjalan. Penulisnya membandingkan dua pendekatan yang dipakai alat sejenis: heuristik yang membaca layar atau judul jendela, dan API di luar jalur terminal seperti socket lokal atau perintah notifikasi khusus. Pendekatan kedua memang lebih baik karena program yang benar-benar tahu statusnya yang melapor, bukan pihak lain yang menebak.

Tapi ada biaya tersembunyi. Setiap program harus berintegrasi dengan setiap kotak masuk secara terpisah, dan socket lokal tidak bekerja melewati SSH atau dari dalam container tanpa jembatan tambahan. Justru itu keunggulan pty: ia bekerja di semua skenario tersebut tanpa penyesuaian, karena setiap program interaktif sudah menulis ke pty-nya sendiri sejak dulu.

Seberapa besar usaha untuk mengimplementasikannya?

Menurut penulisnya, tidak lebih dari selusin baris di setiap kasus. Spesifikasi bahkan menyertakan contoh integrasi lengkap berupa satu fungsi shell pendek yang mencetak sequence ke stdout, lalu dipakai membungkus perintah seperti rsync. Fungsi itu mengubah status menjadi sequence dengan pesan berenkode base64, lalu memanggilnya di awal, di akhir sukses, dan di jalur gagal.

Sifat ini penting untuk adopsi. Kalau menambahkan dukungan berarti memasang SDK, mengonfigurasi socket, atau menulis dependensi baru, sangat sedikit proyek yang akan melakukannya. Karena cukup satu fungsi shell atau satu pemanggilan cetak, biaya menambahkan dukungan praktis nol, dan itu yang membuat protokol seperti ini punya peluang benar-benar dipakai alih-alih jadi spesifikasi bagus yang tidak diimplementasikan siapa pun.

Bagaimana spesifikasinya menangani keamanan dan batas ukuran?

Spesifikasi lengkapnya mencakup bagian keamanan, batas ukuran, siklus hidup record, feature detection, dan terminfo. Semua itu penting karena sequence terminal adalah jalur yang menerima masukan dari program mana pun yang berjalan di dalamnya. Penulisnya menyatakan dokumen itu pendek dan ditulis sepenuhnya dengan tangan, jadi bisa dibaca habis dalam sekali duduk sebelum kamu memutuskan mengadopsinya.

Karena terminal yang baik mengabaikan OSC yang tidak dikenal, program bisa mengirim sequence ini tanpa merusak apa pun di terminal yang belum mendukung. Dukungan bisa ditambahkan bertahap: terminal yang mengerti akan menampilkan status, yang tidak mengerti cukup melewatinya, dan tidak ada pengguna yang melihat karakter aneh di layarnya.

Kenapa protokol ini penting justru untuk agen yang berjalan lama?

Karena jumlah program berdurasi panjang yang berjalan bersamaan terus bertambah: riset latar belakang, pemantauan issue, perbaikan bug, dan pengerjaan fitur besar. Masing-masing bekerja sebentar, lalu berhenti untuk meminta izin, mengajukan pertanyaan, atau melaporkan bahwa pekerjaannya selesai. Kalau kamu menjalankan belasan sekaligus, memantau semuanya dengan mata sendiri menjadi tidak mungkin.

Dari situ muncul kategori alat yang penulisnya sebut kotak masuk agentik: satu tampilan tunggal yang menunjukkan agen mana yang sedang bekerja, mana yang sudah selesai, dan mana yang menunggu keputusanmu. Beberapa contoh yang disebut adalah Herdr, cmux, dan Agent Deck, di antara ratusan alat serupa. Semua alat ini menghadapi masalah yang sama, yaitu bagaimana mengetahui status agen tanpa menebak dari tampilan layar.

Di sinilah OSC 7501 menawarkan jalan keluar yang lebih bersih. Alih-alih setiap alat kotak masuk menulis aturan deteksi sendiri untuk setiap program yang ingin dipantau, programnya cukup melapor lewat satu format yang sama. Jumlah integrasi yang dibutuhkan turun dari perkalian antara jumlah program dan jumlah alat, menjadi penjumlahan keduanya. Untuk ekosistem yang tumbuh secepat ini, perbedaan itu bukan hal kecil.

FAQ

Apakah OSC 7501 hanya untuk coding agent?

Tidak. Penulisnya secara eksplisit menyebut masalah ini generik dan berlaku kuat tanpa membawa AI sama sekali, dan menyarankan pembaca yang tidak peduli soal LLM untuk melewati bagian itu. Build, deployment, upgrade paket, dan pemrosesan data sama-sama diuntungkan karena semuanya berdurasi panjang dan kadang butuh perhatian pengguna.

Apakah program harus memeriksa dukungan terminal dulu?

Tidak wajib. Karena terminal yang baik mengabaikan OSC yang tidak dikenal, program bisa mengirim sequence ini tanpa risiko. Spesifikasi tetap menyediakan bagian feature detection dan terminfo untuk kasus yang membutuhkan kepastian, misalnya bila aplikasi ingin menyesuaikan perilakunya berdasarkan kemampuan terminal.

Kenapa pesannya harus dienkode base64?

Supaya isi pesan tidak merusak struktur sequence. Body protokol ini adalah daftar pasangan key=value yang dipisahkan titik dua, jadi teks bebas yang mengandung pemisah atau karakter kontrol bisa membuat parsing gagal. Dengan base64, satu baris pesan manusia tetap aman dikirim apa adanya, termasuk spasi, tanda baca, dan karakter non-ASCII.

Di mana spesifikasi lengkapnya bisa dibaca?

Spesifikasi lengkap dipublikasikan di situs Superlogical, mencakup siklus hidup record, feature detection, terminfo, batas ukuran, dan bagian keamanan. Penulisnya menyebut dokumen itu pendek dan ditulis sepenuhnya dengan tangan. Untuk versi ringkas beserta alasan desainnya, tersedia juga tulisan pengantar di situs pribadinya.

Sumber

• Mitchell Hashimoto: A Terminal Protocol for Program Status (OSC 7501) (6 Oktober 2026; latar masalah, contoh sequence, dan tabel state).
• Spesifikasi resmi Program Status Protocol (sintaks, daftar kunci, siklus hidup record, dan bagian keamanan).
• Ghostty (emulator terminal tempat salah satu implementasi protokol ini berjalan).
• XTerm Control Sequences (referensi resmi OSC dan escape sequence terminal yang jadi dasar format ini).