Исправление DeepSeek Harness в Safari после 2026: стабильно ли?

Победитель — Safari для повторного пробного использования в задачах с низким риском, но не для безусловного перехода команды: исправление DeepSeek Harness в Safari уже подтверждено для смещения курсора и текста, однако стабильность всего Web UI ещё нужно проверить отдельно. До такой проверки для важных кодовых задач следует сохранить резервный браузер и не полагаться только на состояние вкладки.

Эта статья предназначена разработчикам на macOS, которые отказались от Safari из-за неправильного положения курсора, руководителям, формирующим единый браузерный стандарт команды, и пользователям Agent, постоянно работающим через удалённый Mac.

Last updated: 19 августа 2026 года. Факты сверены с официальным релизом v0.1.0-rc.7 от 17 августа 2026 года, README проекта и руководством Web UI. (официальные заметки к v0.1.0-rc.7)

Что именно исправлено, а что пока нельзя считать доказанным

В релизе v0.1.0-rc.7 прямо указано исправление «Safari composer cursor misalignment» — смещения курсора в поле ввода Safari. В том же выпуске добавлены сворачиваемые карточки вопросов с сохранением черновика, а также обновлён node-pty до версии 1.2 beta для более широкой совместимости PTY.

Из этого следуют три разных вывода:

1. Конкретный дефект поля ввода получил исправление. Это достаточная причина снова запустить короткий тест в Safari.
2. Поведение сложных сценариев не подтверждено автоматически. Длинные многострочные запросы, составной ввод через IME, восстановление вкладки и удалённое переподключение используют разные состояния интерфейса.
3. Стабильная версия ещё не заявлена. README проекта по-прежнему описывает DeepSeek Harness как developer preview и предупреждает о возможных изменениях, нарушающих совместимость. (репозиторий DeepSeek Harness)

Для команды это важное различие. Исправление курсора означает «можно начинать повторную проверку», а не «можно менять корпоративный браузерный стандарт без контрольного периода».

Официальное руководство показывает, что Web UI зависит не только от отображения страницы. После запуска нужно выбрать рабочее пространство, настроить модель и только затем использовать поле отправки задачи. В новой сессии без выбранного workspace composer может оставаться недоступным. (руководство по Web UI)

Почему Safari может выглядеть исправленным, но всё ещё создавать риск

Смешанный ввод — это не обычная печать

Русский текст, английские идентификаторы, символы подчёркивания и команды оболочки проходят через разные этапы обработки. При вводе через IME текст сначала находится в состоянии композиции, затем подтверждается выбором кандидата. Для веб-редактора важно правильно обработать текущий диапазон композиции, позицию курсора и последующее удаление.

Apple отдельно описывает исправления Safari, связанные с потерей диапазона композиции при редактировании через метод ввода. Это показывает, почему тест «написать короткое слово и нажать Enter» недостаточен для оценки IME-сценария. (примечания Apple к Safari 18)

Проверять нужно не субъективное ощущение «курсор вроде на месте», а конкретные переходы:

• вставка русского слова внутрь английского идентификатора;
• выбор варианта в панели кандидатов;
• удаление символа слева и справа от курсора;
• возврат стрелками к уже введённому фрагменту;
• повторная вставка после частичного редактирования.

Если ошибка появляется только после выбора кандидата, это уже отдельный дефект композиционного ввода, а не обязательно повторение прежнего бага.

Длинный текст создаёт другой класс проблем

Многострочный prompt может содержать заголовки, блоки кода, отступы, кавычки и специальные символы. Даже если курсор корректен в первой строке, интерфейс может неправильно обработать:

• выделение через несколько абзацев;
• вставку большого фрагмента одним действием;
• переход в середину кода;
• удаление строки после изменения высоты поля;
• перемещение курсора после автоматического переноса строки.

Веб-редакторы на основе contenteditable и связанных событий редактирования нередко разделяют визуальное выделение, DOM-состояние и внутреннее состояние приложения. WebKit указывает, что JavaScript-редакторы получают не всякую информацию о намерении пользователя одинаковым способом. Поэтому прямое копирование и поэтапное редактирование нужно сравнивать отдельно. (материал WebKit о событиях редактирования)

Черновик не равен сохранённой сессии

В rc.7 заявлено сохранение черновика внутри сворачиваемых карточек вопросов. Это полезно для интерфейса: текст не должен исчезать при сворачивании карточки или переключении видимой части панели.

Но черновик — это состояние UI. Он не доказывает, что:

• запрос уже отправлен;
• сервер сохранил задачу;
• Agent продолжит работу после перезапуска процесса;
• фоновая операция переживёт потерю соединения;
• обновление страницы восстановит все поля в том же виде.

Официальное руководство описывает Web UI как интерфейс для запуска сессии, чтения и изменения файлов, выполнения команд и делегирования задач. Эти операции имеют серверную и файловую часть, поэтому восстановление текста в Safari нельзя автоматически считать восстановлением Agent.

Кэш может скрыть результат обновления

В официальных заметках к rc.7 нет требования обязательно очищать кэш после обновления. Практически разумный порядок другой: сначала перезапустить Web UI, затем сделать обычную перезагрузку страницы, после этого проверить поведение в новой вкладке.

Если интерфейс продолжает показывать старое поведение, Safari позволяет удалить данные конкретного сайта через Safari → Настройки → Конфиденциальность → Управлять данными веб‑сайтов. Apple предупреждает, что удаление данных может завершить вход в сайты и изменить их поведение. (инструкция Apple по управлению данными сайтов в Safari)

Поэтому полная очистка данных Safari не должна быть первым диагностическим действием. Иначе команда потеряет дополнительные признаки: например, станет непонятно, помогло ли само обновление rc.7 или только сброс локального состояния.

Первый этап: короткий ввод как контрольная точка

Начинать нужно с новой сессии, а не с длинного рабочего prompt. Это отделяет исправление редактора от старых данных, сохранённых в конкретной вкладке.

Официальный README показывает запуск Web UI командой:

npx @deepseek-ai/dsh web

По умолчанию сервер сообщает адрес локального интерфейса http://127.0.0.1:3080.

Перед тестом зафиксируйте:

• версию DeepSeek Harness;
• версию Safari;
• версию macOS;
• локальный или удалённый способ доступа;
• новую или уже существовавшую сессию;
• включённый способ ввода;
• факт очистки данных сайта.

Затем выполните минимальный цикл:

1. Введите короткую фразу.
2. Переместите курсор в середину.
3. Добавьте одно слово.
4. Удалите символ слева и справа.
5. Выделите часть строки.
6. Отправьте запрос.
7. Создайте вторую короткую фразу и повторите цикл.

Пример тестового текста:

Проверьте строку apiClient и замените только имя переменной.

Ожидаемый результат должен быть проверяемым: каждый символ остаётся в нужной позиции, выделение не перескакивает, после отправки в истории отображается именно тот текст, который был подготовлен до нажатия кнопки.

Ожидаемый вывод:
курсор — в выбранной позиции
текст до отправки — совпадает с текстом после отправки
пропавшие символы — нет
самопроизвольная перестановка фрагментов — нет

Если этот этап не пройден, Safari пока не подходит даже для низкорисковых рабочих задач. Нет смысла переходить к проверке удалённого переподключения, пока базовый редактор не выдерживает короткий цикл.

Второй этап: смешанный русский и английский ввод

Для macOS этот тест важнее, чем простая вставка готового текста. Используйте образец без ключей, токенов, адресов серверов и содержимого реального репозитория:

Исправьте функцию fetchUser() и проверьте поле user_id в API-клиенте.

Порядок проверки:

1. Наберите русскую часть через системную раскладку.
2. Переключитесь на английскую.
3. Введите имя функции и подчёркивание.
4. Вернитесь к русскому фрагменту.
5. Измените окончание слова.
6. Удалите один символ внутри имени функции.
7. Вставьте короткий фрагмент из буфера.
8. Отмените и повторите последнее действие, если Web UI это поддерживает.
9. Отправьте результат только после визуальной и посимвольной проверки.

Не ограничивайтесь итоговым скриншотом. При проблеме сохраните точную последовательность: какая раскладка была активна, на каком символе появился сдвиг, выполнялся ли выбор кандидата, использовалась ли вставка, менялась ли высота поля.

Важное ограничение: результат одного Mac нельзя расширять на весь парк. Разные версии macOS, Safari, раскладки и политики удалённого доступа могут давать разные события ввода.

Третий этап: длинный prompt и кодовый фрагмент

Длинный тест должен проверять не объём сам по себе, а операции над текстом. Не используйте секреты и рабочие ключи. Подойдёт обезличенный фрагмент:

Найдите причину ошибки в обработчике ответа.

```js
async function loadData(url) {
  const response = await fetch(url);
  return response.json();
}

Сравните два способа:

• вставить весь текст одним действием;
• набрать заголовок, затем вставить код и вручную изменить одну строку.

В каждом варианте проверьте:

• сохраняются ли переводы строк;
• не исчезают ли обратные кавычки;
• не меняется ли отступ;
• можно ли выделить часть кода через границу абзаца;
• остаётся ли курсор в месте редактирования;
• не дублируется ли фрагмент после вставки;
• совпадает ли текст в карточке после отправки.

Для важных задач полезно сначала сохранить prompt локально:

cat > dsh-safari-test.txt <<'EOF'
Тестовый текст без секретов.
Проверка длинного ввода и кода.
EOF

Эта команда не проверяет DeepSeek Harness напрямую. Она создаёт резервную копию исходного текста, чтобы ошибка браузера не превратилась в потерю задания.

Четвёртый этап: карточки, черновики и переключение состояния

После коротких и длинных запросов проверьте именно новые элементы rc.7. Создайте вопрос, введите несколько строк, сверните карточку, переключитесь на другую область интерфейса и вернитесь обратно.

Затем проверьте четыре состояния:

1. текст остаётся после сворачивания;
2. текст остаётся после разворачивания;
3. курсор возвращается в ожидаемую область;
4. черновик не подменяется уже отправленным сообщением.

Отдельно выполните обновление вкладки. Если текст исчез после обновления, это не обязательно означает нарушение заявленного сохранения черновика: нужно установить, где именно функция гарантирует сохранение. В релизе речь идёт о карточках вопросов и интерфейсном черновике, а не о полном журнале сессии.

Для команды результат лучше фиксировать не оценкой «работает нормально», а записью:

Сценарий: сворачивание карточки
До действия: 3 строки, курсор после второго абзаца
Действие: свернуть → открыть → перейти к другой карточке
Результат: текст сохранён / текст изменён / курсор потерян

Такой формат облегчает сравнение между устройствами и не смешивает субъективное впечатление с воспроизводимым дефектом.

Пятый этап: удалённое переподключение без подмены понятий

Удалённый Mac добавляет минимум три независимых риска:

• вкладка Safari может потерять соединение;
• Web UI может восстановить оболочку, но не локальное состояние формы;
• Agent может продолжить серверную задачу, даже если вкладка не восстановилась.

Поэтому тестируйте их отдельно. Сначала введите черновик и имитируйте краткую сетевую паузу. Потом отправьте безопасный запрос и проверьте, что он появился в истории. Затем обновите вкладку и отдельно проверьте фоновый процесс или Job Panel.

Релиз упоминает управление задачами дочерних Agent через Job Panel, но это не означает, что восстановление вкладки Safari автоматически перезапускает или продолжает каждую задачу.

Для удалённого доступа используйте такой порядок:

1. Установите базовую связь с Mac.
2. Откройте Web UI в новой вкладке Safari.
3. Выберите workspace.
4. Введите короткий тестовый prompt.
5. Проверьте отправку.
6. Отключите сеть на короткий интервал.
7. Восстановите соединение.
8. Запишите состояние черновика.
9. Обновите вкладку.
10. Проверьте историю, активную сессию и фоновую задачу раздельно.

Для критических операций заранее сохраняйте prompt и идентификатор задачи. Если удалённый Mac используется постоянно, полезно также документировать способ доставки, задержку переподключения и наличие резервного доступа. Общие сведения о работе с удалённой средой можно посмотреть на главной странице SFTPMAC, а браузерный тест всё равно нужно выполнять на конкретной связке macOS и Safari.

Опыт эксплуатации: восстановившаяся вкладка — это только признак возврата интерфейса. Она не подтверждает сохранность черновика, запроса и процесса Agent одновременно.

Как принять решение после первой проверки

Используйте условия, а не общее впечатление от обновления.

• Если короткий ввод, смешанная раскладка, вставка кода и сворачивание карточки проходят без потери текста, то Safari можно вернуть для низкорисковых задач.
• Если базовый ввод работает, но длинный текст или IME дают ошибку, то Safari оставляют только для коротких запросов, а резервный браузер сохраняют для кода.
• Если черновик сохраняется в карточке, но после переподключения исчезает, то это интерфейсный успех, но не основание доверять Safari для длительных Agent-сессий.
• Если после обновления поведение похоже на старую версию, то сначала перезапускают Web UI, затем удаляют данные только нужного сайта и повторяют тест.
• Если одна и та же ошибка повторяется на нескольких устройствах с одинаковой версией, то фиксируют воспроизведение и не переводят команду на Safari до следующего исправления.
• Если задача критична для релиза, миграции или изменения рабочей ветки, то используют резервный браузер и локальную копию prompt независимо от результата короткого теста.

Официальный README предупреждает о возможных несовместимых изменениях, поэтому единый браузерный стандарт команды лучше утверждать после повторной проверки на нескольких связках macOS и Safari, а не сразу после выхода одного предварительного релиза.

Матрица проверки для команды

Три режима использования после обновления

Для повторной проверки команды удобно вести один файл с версией, датой, устройством и результатом каждого сценария. Актуальные варианты удалённой среды следует оценивать отдельно от браузерной совместимости: стоимость и конфигурация Mac не заменяют приёмку поля ввода, черновиков и переподключения.

Safari, резервный браузер или отдельный Mac: что выбрать

Для постоянной тяжёлой нагрузки собственный Mac может быть рациональнее аренды: не будет зависимости от доставки, удалённого канала и правил доступа. Но для временной проверки Safari, повторения теста на другой среде или командного пилота отдельный Mac через SFTPMAC удобнее, чем менять рабочую машину только ради одного браузерного эксперимента.

При этом текущий подход на одном локальном Mac имеет два заметных минуса — трудно быстро сравнить несколько сред и сложно отделить локальный сбой от проблемы Web UI. Удалённая аренда не отменяет приёмку, зато позволяет повторить тот же сценарий на выделенной среде без немедленной покупки оборудования. Подходящую удалённую среду следует выбирать только после того, как требования к браузеру, доступу и восстановлению сессии зафиксированы в тестовой матрице.

FAQ

Исправлена ли проблема со смещением курсора в Safari?

Да, в официальных заметках к v0.1.0-rc.7 прямо указано исправление смещения курсора и текста в поле ввода Safari. Это подтверждает устранение конкретного дефекта, но не доказывает совместимость всех сценариев Web UI. После обновления отдельно проверьте смешанный ввод, длинный текст, вставку кода, черновик и поведение после обновления страницы.

Можно ли считать Safari стабильным браузером для DeepSeek Harness Web UI?

Пока нет оснований объявлять Safari полностью стабильным вариантом. Проект всё ещё находится в режиме предварительной версии и предупреждает о возможных несовместимых изменениях. Safari можно вернуть для низкорисковых задач после локальной проверки, но для важных кодовых операций лучше оставить резервный браузер и сохранять тексты до отправки.

Нужно ли очищать кэш после перехода на rc.7?

Не обязательно: в официальном описании релиза нет требования очищать кэш после обновления. Сначала выполните обычную перезагрузку страницы и проверьте версию сборки. Если интерфейс сохраняет старое поведение, удалите данные только для нужного сайта в настройках Safari. Полная очистка может завершить вход в сайты и изменить их поведение.

Что проверить при удалённом использовании Safari на Mac?

Проверьте не только поле ввода, но и разделите состояние браузера и состояние сервера. Введите короткий текст, выполните смешанный русско-английский ввод, вставьте многострочный код, сверните карточку с черновиком, обновите вкладку и имитируйте краткий сетевой сбой. Отдельно подтвердите, сохранились ли отправленный запрос и фоновая задача.

Для первого прохода достаточно составить таблицу из пяти сценариев, записать точные версии macOS, Safari и DeepSeek Harness, а затем повторить её после следующего обновления. Такой подход быстрее субъективного вывода «Safari снова работает» и показывает, в каком именно месте Web UI ещё требует резервного браузера.