omo-senpi 타입체크는 체크아웃 위치와 관계없이 동일한 결과를 냅니다. 이전에는 체크아웃 상위 폴더의 @types/node를 가져와서, 같은 커밋에서 CI는 통과하는데 그 폴더에 남아 있던 오래된 복사본 때문에 타입체크가 실패할 수 있었습니다. 이제 omo-senpi는 자체 @types/node와 bun-types를 선언하고, 타입 패키지를 자신의 node_modules에서만 읽습니다. (#10320, #10332)
메모리 항목은 오래된 기기에서 동기화하더라도 동시 편집을 잃지 않습니다. 동기화 항목 모델은 기기의 편집을 해당 기기가 본 정확한 스냅샷 기준으로 기록하므로, 오래된 캡처는 조용히 작업을 버리거나 오류를 던지는 대신 동시 편집으로 병합됩니다. 같은 기준 스냅샷에서 한 기기가 만든 두 캡처는 아무것도 잃지 않으며, 여러 줄 및 따옴표로 감싼 frontmatter 값은 모든 레플리카에서 유효한 YAML로 렌더링됩니다. 하나의 파일을 여러 개로 나눌 수 있는 경로 키(빈 세그먼트, 끝의 슬래시, 백슬래시, 드라이브 문자)는 정규화하지 않고 거부합니다. 아직 서버로 동기화되는 것은 없습니다. (#10203)
에이전트 이름과 같은 categories 항목은 이제 무시되는 대신 경고가 표시됩니다. task(subagent_type: "plan-consultant") 생성은 agents."plan-consultant"만 읽으므로, categories."plan-consultant" 아래에 둔 모델 체인은 전달되지 않아 생성이 내장 체인으로 실행되었고, 그동안 omo doctor는 해당 카테고리를 사용 가능한 것으로 계산했습니다. 이제 categories.<name> 키가 내장 에이전트 또는 agents 설정의 에이전트와 같고, 그 에이전트가 자체 모델을 설정하지 않은 경우, 시작 시 알림과 omo doctor가 해당 키는 그 생성에서 읽히지 않는다고 알려주고, 사용자의 체인을 넣은 수정된 스니펫(예: "agents": { "plan-consultant": { "models": [...] } })을 보여줍니다. 에이전트의 모델을 설정하는 방법은 여전히 agents.<name>.models 하나뿐입니다. 해석 방식은 변경되지 않았습니다. 보고해 주신 @Bearmancer께 감사드립니다. (#10323, #10326)
백그라운드 작업에 대한 조종(steering) 메시지는 실패와 전달이 동시에 기록되지 않습니다. steer가 시간 초과되고 재시도가 아직 진행 중일 때, 부모의 이후 실행이 작업의 미확인 입력을 조정하면, 그 실행은 메시지를 실패로 표시했고 이후 재시도가 메시지를 전달해 작업 로그에 두 결과가 모두 남았습니다. 이제 조정은 재시도가 진행 중인 입력을 그 재시도에 맡기며, 재시도가 실제 결과 하나만 기록합니다 (#10165).
세션 디렉터리가 아직 없을 때 메모리 리플렉션이 샌드박스에서 더 이상 실패하지 않습니다. Linux 샌드박스는 이제 바인딩하는 각 쓰기 가능 디렉터리를 bwrap이 바인딩하기 직전에 (모드 0700으로) 생성하며, 모든 리플렉션 실행은 먼저 identity의 런타임 디렉터리를 채워 넣습니다. 그래서 runtime/reflection-sessions가 생기기 전에 만들어진 identity도 "Can't find source path" 오류 없이 정상적으로 리플렉션합니다. 샌드박스가 꺼져 있거나 사용할 수 없는 경우에는 여전히 아무것도 만들지 않습니다. @leeseunguk와 @AceRothstein71께 감사드립니다 (#7236). (#7012, #8004)
누락된 리플렉션 디렉터리에 대해 더 이상 "샌드박스를 끄라"는 안내가 나오지 않습니다. 샌드박스 바인드 디렉터리가 아직 없어서 메모리 리플렉션이 실패하면, 이제 알림에서 해당 디렉터리를 명시하고 생성 방법을 안내합니다. 이전처럼 사용자 네임스페이스를 원인으로 지목하고 memory.reflection.sandbox: "off"를 권장하지 않습니다. 실제 사용자 네임스페이스 거부는 여전히 호스트 쪽 해결책을 먼저 안내하며, 샌드박스 끄기는 최후의 수단으로만 안내합니다. (#10317, #10319)
메시지 없이 OmO 세션을 열고 닫아도 /resume에 빈 세션이 남지 않습니다. 메모리 컴포넌트의 숨겨진 세션 바인딩이 이제 시작 시 내부 관리 데이터로 기록되므로, 대화가 한 번도 없었던 세션은 senpi가 제거합니다. (#10168, #10308)
작업 샤드 호스트는 이제 며칠씩 살아 있는 대신 자식 작업이 끝나면 종료합니다. 작업 자식의 세션이 샤드에서 대기 상태가 되거나 닫히면, 자식이 해당 샤드에 맺은 연결이 열린 채로 남아 샤드가 연결을 계속 세었고, 그래서 유휴 종료가 실행되지 않았습니다. 한 샤드는 이틀 동안 세션을 0개 처리하면서 자기 자신에게 연결된 18개의 연결을 유지했습니다. 이제 세션이 끝나면 이 연결들이 닫히며, 거부된 닫기 요청 때문에 클라이언트가 방치되지 않습니다 (#10062, #10066).
Computer use는 키나 마우스 버튼을 지정된 시간 동안 누른 상태로 유지하고, 항상 떼어 줍니다. holdKeys(keys, { duration })와 holdMouse(x, y, { duration })는 최대 100초 동안 누른 상태를 유지하며, 실행이 취소되거나 비상 정지가 발생해도 눌렀던 모든 입력을 역순으로 해제합니다. (#9651, #10030)
자식 작업은 실제로 실행 중인 모델을 계속 보고합니다. 어떤 클라이언트든 자식에게 적용한 set_model 또는 모델 순환, 그리고 이후 되돌아가는 폴백은 발생 즉시 자식의 기록을 갱신합니다. task_output, /tasks, 데스크톱 작업 스냅샷, 완료 알림 모두 현재 모델을 보여주며, omo가 수행하지 않은 전환에는 (switched by operator)가 표시됩니다. 저장된 기록의 effective_model.source는 이전 빌드가 파싱할 수 있는 값으로 유지되며(실시간 전환 세부 정보는 이전 빌드가 무시하는 중첩 블록으로 이동), 따라서 다운그레이드했거나 작업 저장소를 공유하는 이전 omo도 이 기록을 로드할 수 있습니다. (#10020, #10097)
OMO_DISABLE_TELEMETRY=1은 OmO Native 텔레메트리를 완전히 끄며, 옵트아웃된 세션은 나중 세션이 전송할 수 있는 데이터를 남기지 않습니다. 모든 옵트아웃(OMO_DISABLE_TELEMETRY, DO_NOT_TRACK, PostHog 스위치, 설정 플래그)은 이제 하나의 동의 확인을 거치며, 이 확인은 세션 시작 시와 무언가를 기록하거나 해시하기 직전에 다시 수행됩니다. 옵트아웃된 세션은 세션 해시를 만들지 않고, salt나 고지 마커를 생성하지 않으며, 요약 파일도 쓰지 않습니다. 이벤트에는 이제 시간순 정렬이 가능한 무작위 event_id가 포함되고, 기기 대신 설치 ID의 해시로 식별되며(이전 기기 해시는 2026-12-14까지 함께 전달되어 기존 행과 연결됩니다), CI 실행은 단순한 ci 플래그로 표시됩니다. 세션 실행 중에 텔레메트리를 끄면, 해당 세션의 이벤트가 몇 초 안에 중단되며, 샘플링된 세션이 계속 보내던 턴별 원시 행도 포함됩니다 (#10328). 실제 런타임을 시작하는 QA 드라이버는 하나의 공용 헬퍼를 통해 텔레메트리를 옵트아웃합니다. (#10226)
수정됨: OmO Native v5.0.0-beta.6부터 v5.1.34까지의 버전은 세션 실행 중에 텔레메트리를 끈 뒤에도 해당 세션이 끝날 때까지 사용량 이벤트를 계속 전송했습니다 (#10328). 이 이벤트들은 개인을 식별하지 않으며 세션 해시를 포함합니다. 해당 보고에서 확인된 이벤트는 turn_completed, feature_used, computer_use_activation이며, 다른 사용량 이벤트도 같은 방식으로 전송되었을 수 있습니다. 모든 OmO Native 이벤트와 마찬가지로 프롬프트나 응답 텍스트, 파일 경로, 파일 내용은 포함하지 않습니다. 세션 시작 전에 텔레메트리를 끄거나 옵트아웃 환경 변수를 통해 끈 경우에는 이 문제의 영향을 받지 않았습니다. v5.1.35부터는 이벤트를 전송할 때 동의를 확인하며(확인 결과는 최대 5초 동안 재사용됨), 옵트아웃이 읽히면 이미 대기 중인 이벤트는 버려집니다. 이 이벤트들은 동의한 이벤트와 구별할 수 없으므로, 삭제는 설치 단위로 진행합니다. 이 저장소의 비공개 취약점 신고 양식을 통해 "Telemetry erasure request"라는 제목으로 비공개 요청을 보내고, 설치 ID(에이전트 홈 아래의 omo-senpi/omo-native/install-id 파일)를 함께 제출하면, 운영자가 해당 설치의 이벤트를 삭제합니다. 설치 ID는 공개 이슈나 댓글에 쓰지 말고 비공개 신고에만 넣어 주세요. 기기 해시로만 식별되는 이전 버전의 이벤트는, 우리 기록이 해당 해시를 설치 ID와 다른 설치 없이 짝지을 수 있는 경우에만 설치의 이벤트와 함께 삭제됩니다. 여러 기기나 설치가 공유하는 이력(같은 호스트명 해시)은 이런 방식으로 삭제되지 않습니다. 비공개 요청에서 이를 명시해야 하며, 요청이 해당 이벤트가 본인의 것임을 증명할 경우에만 삭제됩니다. (#10226)
메모리 궁전과 /people이 처음 사용될 때 로드되므로, 세션 시작 시 약 33 KB의 코드가 덜 로드됩니다. /palace 뷰어 생성기와 /people 명단, 기록, --ask 런타임이 진입 번들에서 별도 파일로 옮겨졌으며, 두 명령 중 하나가 처음 실행될 때 로드됩니다. 이는 /doctor와 /memfs가 이미 동작하는 방식과 같습니다. 두 명령은 이전과 정확히 같은 내용을 출력하고 알림도 같습니다. 해당 파일이 없거나 손상된 경우, 명령이 이를 알리고 omo를 다시 설치한 뒤 새 세션을 시작하라고 안내합니다. 이전에는 조용히 실패했습니다. (#10300)
메모리 동기화 기기 키링은 이제 잘못된 입력을 나중에 실패하는 대신 더 일찍 거부합니다. 키링 레코드는 더 이상 스냅샷 태그를 타입으로 가질 수 없고, 깊이가 64단계를 넘는 중첩 JSON은 스택 오버플로 대신 타입이 지정된 오류로 거부됩니다. 래핑 연관 데이터는 단일 RFC 8785 직렬화기를 거치며, 정수가 아닌 epoch는 거부됩니다. 저차(low-order) X25519 점은 일반적인 "does not open" 오류로 거부됩니다. 이는 #10194 검토에 대한 후속 조치입니다 (#10274).
백그라운드 작업 재연결이 중복 작업을 시작하는 대신 실제 결과를 복구합니다. 다시 로드되거나 호스트 연결을 잃은 부모는, 자식의 기록을 읽기 전에 자식이 아직 실행 중인지 확인합니다. 완료된 턴은 한 번만 채택되고, 중단된 턴은 한 번만 계속되며, 마감 시간에 중지된 턴은 명시적인 task_send 전까지 중단 상태를 유지합니다. (#10012, #10013, #10078).
ulw-research 보고서 검사기는 보이지 않는 이미지를 보고서의 시각 자료로 더 이상 계산하지 않습니다. 높이나 너비가 0인 이미지나 차트(예: width="600" height="0" 또는 인라인 height: 0)는, 모든 최종 보고서에 시각 자료가 있어야 한다는 규칙을 더 이상 충족하지 못합니다. 선언된 크기가 없는 이미지는 브라우저가 크기를 정하므로 여전히 인정됩니다. (#10266, #10268)
Computer use는 전체 접근 모드에서 전경 제어에 대해 더 이상 확인을 요청하지 않습니다. 전체 접근 세션은 이를 바로 허용하고 그 이유를 알리는 메모를 표시합니다. 다른 모드는 여전히 확인을 요청하고, 헤드리스 실행은 여전히 절대 허용하지 않으며, 허용은 턴이 끝나거나, 해제되거나, 중지 단축키를 누를 때 함께 종료됩니다. Q님이 보고해 주셨습니다. (#10022, #10024)
omo update는 패키지 관리자가 설치한 바이너리를 덮어쓰겠다고 더 이상 제안하지 않습니다. 컴파일된 omo를 pacman, dpkg, rpm, Homebrew, Nix 중 하나가 소유한 경우, omo update는 이전에 curl … && mv 교체 명령을 출력했는데, 이는 root 소유 경로에서 실패하거나 패키지 관리자가 더 이상 설치하지 않은 파일을 계속 추적하게 만들었습니다. 이제 0이 아닌 코드로 종료하며, 패키지 이름과 패키지 관리자의 업그레이드 명령(예: brew upgrade omo)을 안내합니다. 소유권 확인은 실패 시 허용하는 방식으로 동작합니다. 도구가 없거나 소유되지 않은 경로라면 기존 동작을 유지합니다. @cynkai께 감사드립니다. (#9585, #9629)
메모리 리플렉션 알림이 실패한 실행의 로그를 실제 경로로 지정합니다. 대기 알림, 리플렉션 실패 상태 경고, /memory doctor는 이전에 runtime/reflection-sessions/<runId>/child-stderr.log를 확인하라고 안내했습니다. 이는 상대 경로이면서 문자 그대로 <runId>가 들어 있고, 실행 기록이 보관되지 않는 디렉터리 아래에 있었습니다. 이제 가장 최근에 실패한 실행의 절대 경로 child-stderr.log를 안내합니다(홈 경로는 ~로 줄임). 해당 실행이 이미 정리되었다면 그 사실을 알리고, 실패 세부 정보에 보관된 stderr 끝부분을 가리킵니다. @cynkai께 감사드립니다. (#9497, #9505)
분량 관계로 이후 내용은 번역에서 제외했습니다. 전체 내용은 위 원문 링크에서 확인하세요.