{"version":"2.1.235","anchor":"terminal-recordings-can-be-stored-under-storage-v5-with-a-r","canonical_anchor":"terminal-recordings-can-be-stored-under-storage-v5-with-a-r","heading":"Terminal recordings can be stored under storage v5 with a 'recording' namespace","tier":"soon","area":"Terminal Recordings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235\/e\/terminal-recordings-can-be-stored-under-storage-v5-with-a-r","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235","markdown":"### Terminal recordings can be stored under storage v5 with a 'recording' namespace\n\nTerminal (asciicast) recordings can now be listed and renamed through storage v5's 'recording' namespace instead of only the filesystem\n\n**Unclear.** What triggers the storage-backed path versus the filesystem fallback in practice is not specified.\n\nAsciicast recordings gain a storage-backed path under storage v5, keyed by a `recording` namespace that includes project, session, and timestamp. Listing recordings now merges on-disk `.cast` files with entries held in this storage namespace, and renaming a recording can go through a parked callback registered on the recorder rather than a direct filesystem rename.\n\nThe previous behavior, renaming the file directly to `<sessionId>-<timestamp>.cast`, remains as a fallback.\n\n- Flag `tengu_hover_rest`: Off in both readings (read for one account on one subscription tier against v2.1.235; this account: off, anonymous baseline: off, compiled default: off)\n- Area: Terminal Recordings\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}