Codex 0.164.0で親AGENTS.mdを1B増やすと、子が起動時一覧から消えた

Last updated at 2026-10-27Posted at 2026-10-22

親のAGENTS.mdを32,767Bから32,768Bへ1B増やすと、同じ60Bの子ファイルがCodexの起動時一覧から消えました。 合計32KiB上限の境界を、合成データで確認した結果です。

親のサイズ	同じ子AGENTS.md（60B）の起動時一覧
32,767B	掲載あり
32,768B	掲載なし

macOS / Node22.23.4 / 正式版Codex0.164.0で、子フォルダーから起動しました。子ファイルは2条件で同じSHA-256です。一覧の差はCodexの応答の観測で、残りのバイト数は別のローカル見積りです。モデルへの全文受信やルール遵守の検証とは分けて扱います。

実測JSON・入力ハッシュ・再実行スクリプトを公開しています。以下の1コマンドで、自分の起動フォルダーも点検できます。

AGENTS.mdを変更したあと、Codexが起動時にどのファイルを選ぶかを、自分の作業フォルダーで点検するための記事です。ファイルの選択、別のローカル容量見積り、新規セッションが目印を返せたかを分けて扱います。

試し方を選ぶ（現行の共通v0.1.4）

手元の起動状態を見る：既存のNode22+/Codex CLIがあれば、下のinspectを使います。
ローカルCLIやAPI認証を準備せずに試す：子フォルダー用のCI導入手順へ。本文にも、同じv0.1.4を使うworkflowを載せました。GitHub Actionsの利用枠は必要です。

先に自分のフォルダーを点検する

既存の Node22+・npm/npx・stable Codex CLI 0.163.0/0.164.0 があれば、普段Codexを起動する自分のプロジェクトフォルダーで、次の1コマンドを実行できます。ZIPの展開や別フォルダーへの移動は不要です。

npx --yes --ignore-scripts --allow-remote=root \
  --package="https://aichance.github.io/business-ai-recipes/agent-relay-check-v0.1.4-npx1.tgz" \
  agent-relay-check inspect --project "$PWD"

このコマンドは、公開済みの共通v0.1.4の24ファイルと、起動用の2ファイルをnpmのキャッシュへ取得して実行します。npm依存・install hookはなく、プロジェクトへの依存追加やCodexのインストール・ログイン操作はしません。--allow-remote=rootはnpm12でこの直接URLの取得を明示するコマンド単位の指定で、保存設定は変更しません。ソース・SHA-256・PowerShell・検証範囲を確認できます。

元の共通v0.1.4 ZIPも使えます。展開したagent-relay-checkフォルダーから、従来どおりnode cli.mjs inspect --project "/absolute/path/to/your-project"を実行してください。

10月28日確認：正式CLI 0.165.0は、この共通v0.1.4のバイト見積もりの検証済み範囲外です。 新版を対応済みとは扱いません。上の1コマンドの公開URLからの実行確認は、macOS / Node22.23.4 / npm12.2.1 / CLI0.164.0の合成プロジェクトで行いました。モデルturnは0、指示ファイルは不変で、起動した2サーバーの終了を確認しました。これは運営側の包装・導入検証で、読者の実利用には数えていません。

estimate.native_project_sourcesがCodexの選んだファイル、estimate.rowsが別のバイト見積りです。モデルturnの要求と指示ファイルの編集はありません。 通常のCodex初期化による通信・ローカルmetadata書込はあります。対応外の版や設定不明はINCONCLUSIVEです。ソース・コマンドの作用・検証範囲を確認できます。

この点検だけでは、内容をモデルが受信したか、ルールを守るかは判定しません。以下では、子に空のAGENTS.override.mdを追加すると合言葉が返らず、除去すると再び返った過去の対照実験と、別途1turnを使う受信確認を説明します。新しい起動時点検の入口を加えましたが、元の実測は変更していません。

10月28日追記：子フォルダーをCIで検査する（共通v0.1.4）

ローカルCLIの準備やCodex認証をせず、自分が管理するリポジトリの変更をGitHub Actionsで確認する入口です。次を.github/workflows/check-guidance.ymlとして保存します。

apps/webは普段Codexを起動する実在のフォルダーへ、required-filesは必須の指示ファイルへ置き換えてください。必須パスは起動ディレクトリ基準ではなくGitルート基準です。例のフォルダーや必須ファイルがなければ失敗します。

name: Check Codex startup guidance
on: [push, pull_request, workflow_dispatch]
permissions:
  contents: read
jobs:
  guidance:
    runs-on: ubuntu-24.04
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
        with:
          persist-credentials: false
      - uses: aichance/business-ai-recipes/tools/agent-relay-ci-v014@daab5bc86f063b5cae21ce6c80d3489da72a117b
        with:
          project-directory: apps/web
          required-files: |
            AGENTS.md
            apps/web/AGENTS.md

この例は、親AGENTS.mdと子apps/web/AGENTS.mdの両方を要求します。ルートでしか起動しないリポジトリなら、project-directory: '.' / required-files: AGENTS.mdに変更できます。

固定SHAのアクション実装を使い、GitHub-hosted Linuxへ公式Codex0.164.0と、ダウンロードと同じ共通v0.1.4を一時導入します。モデルturn・Codexログイン・APIキーは不要です。初期化通信・一時メタデータ作成とGitHub Actionsの通常の利用枠は使います。指示ファイルは書き換えません。

結果は実行画面のSummaryに出ます。

結果	このCIで確認したこと
`PASSED`	必須パスがnative一覧にあり、別のローカル見積りが全バイト`FULL`。検査中のファイルが安定し、検査用サーバーの終了も確認。
`REJECTED`	必須パスの欠落・途中切れの見積り・対象パス不正など。
`INCONCLUSIVE`	対応外・設定由来が不明・中断などで確認できず。成功扱いにせずstepを失敗させます。

目印の受領と指示の遵守は、どの結果でもNOT_TESTEDです。 CIはcheckoutした指示と設定の起動状態を調べます。デスクトップの個人設定・ログイン状態、Claudeのimport、hooks/skillsの動作を再現するものではありません。目印の到達が必要なら、後述の認証済みローカルrun --liveを使います。

必須の相対パス名と要約は実行Summaryに表示されます。実行を許可できる、確認済みの指示・設定を使い、secretsや個人の設定をこのjobへ追加しないでください。任意の悪意あるリポジトリを安全に調べるsandboxではありません。作用・制約・公開workflow定義に詳しく記載しています。

下記の「10月25日追記：CI」とそこで引用する実行結果は、旧v0.1.3の履歴です。上のv0.1.4と同じ版・同じ利用者実績として合算していません。

AGENTS.mdを置いたあと、意図した経路で内容がモデルへ渡っているかを確認したくなりました。

今回は、親と子の指示ファイルに別々のランダムな合言葉を置き、子ディレクトリから新しいCodexセッションを開始しました。子に空のAGENTS.override.mdを追加すると子の合言葉が返らず、除去すると再び返りました。親の合言葉は3回とも返りました。

これは既存のCodex issue #54755を参考にした、合成データでの追加検証です。新しい不具合を発見したという主張ではありません。また、合言葉が返らないことだけで「内容が絶対に届いていない」とは判定しません。

10月25日追記：live検査のモデルを明示できるv0.1.4

現行v0.1.4では、runに--modelと--effortを任意で指定できます。既定は引き続きgpt-6.1-sol / MAXです。live検査がINCONCLUSIVEとなり、モデルの認証・利用枠に言及した外部の試行報告を受け、普段すでに使えている設定を明示する入口を追加しました。ログインや利用枠の不足を修復する機能ではありません。

運営側で実モデル検証したのは6.1Sol/MAXの既定指定と明示指定です。 別のモデル・推論設定を運営側が実機検証した結果ではありません。10月27日に確認したWindows作者1人の外部報告は、下記で条件を分けて示します。指定値と起動セッションの実効設定が一致しなければ、モデルturnを要求する前にINCONCLUSIVEにします。自動のモデル切替・再試行はしません。指定方法、変更箇所、検証の範囲。

10月27日追記：Windows作者1人によるv0.1.4の受信報告

FramY2さんの公開報告では、Windows 11 / Node24.11.1 / Codex0.163.0-alpha.11.2で、共通v0.1.4と既存の gpt-6-luna / medium を明示し、使い捨てプロジェクトの追記前 NOT_OBSERVED → 追記後 RECEIVED を確認したとされています。同じchallengeで、要求値と実効model/effortの一致・tool call 0・cleanup確認を報告しています。

これは独立した作者によるその1環境の自己申告で、こちらがWindowsや別モデル全般を検証した結果ではありません。alpha CLIのbyte見積り、指示全体の受領・遵守、通常業務への定着は未確認です。記事中のmacOS対照実験は当時の版のまま保ちます。別モデルを使う場合も、手元ですでに動く設定を明示し、自動fallbackで置き換えません。

以下の初回・変更後の手順は既定設定のままでも使えます。モデル要求を避けるならinspect、ローカルCLIがなければ次のCI手順を選べます。この記事の過去の実測と、下記の旧v0.1.3のCI記録は残しています。新規CI導入は上の「10月28日追記」のv0.1.4を使います。

10月25日追記：ローカルCLI・APIキーなしでCIから試す

GitHub Actionsの導入手順を公開しました。自分のリポジトリへ任意のworkflowを追加し、必要な指示ファイルと起動ディレクトリを指定できます。GitHub-hosted Linuxに公式Codex0.164.0を一時導入し、共通v0.1.3でnativeのパス掲載と、別のローカルFULLバイト推定を検査します。モデルturn・Codexログイン・APIキーは不要ですが、初期化時の通信・一時メタデータ作成と通常のGitHub Actions利用枠の消費はあります。

運営者のCI対照では、通常成功、子ファイルの途中切れ、必須ファイル欠落、対象外フォルダーの拒否を確認しました。掲載されていても、別のローカル推定が途中切れなら成功にしません。合言葉の受領とルール遵守はNOT_TESTEDのままです。CI環境の確認であり、手元の個人設定やログイン状態を再現するものではありません。対象と制約、固定SHA付きのworkflow全体は導入手順にあります。

何を比べたか

冒頭の3条件はv0.1.0の記録です。2026年10月22日、macOS、Codex CLI 0.163.0、gpt-6.1-sol / MAXで検証しました。Codex app-server経由で、各条件を1回ずつ、新しいセッションとして実行しています。同じ一時Gitプロジェクトのservice/を起動位置にし、各回で合言葉を生成し直しました。

temporary-project/
├── AGENTS.md                  # root_probe の合言葉
└── service/                   # 3回とも、ここから開始
    ├── AGENTS.md              # service_probe の合言葉
    └── AGENTS.override.md     # 2回目だけ存在する空ファイル

条件	root_probe	service_probe	所要時間
overrideなし	RECEIVED	RECEIVED	23.101秒
子に空のoverrideを追加	RECEIVED	NOT_OBSERVED	14.130秒
空のoverrideを除去	RECEIVED	RECEIVED	12.228秒

3回ともセッションとturnの完了、クライアントが報告するモデル・推論設定と指定値の一致、起動した検査プロセスの終了を確認しました。provider内部のモデル経路を独立に監査したわけではありません。観測したtool呼び出しは0件です。所要時間は各1回の観測値で、性能比較ではありません。結果は元のissueへの検証報告にも記載しています。

「正解した」だけでは分からないこと

質問に合言葉を書けば、指示ファイルを読まなくても答えられます。また、モデルが途中でファイルを開いて答えた場合、起動時に渡った証拠にはなりません。

この区別には先行する検証があります。Matsunさんの配置別実測は、子の規則を後からrgやcatで取得したケースをログから切り分けています。AINewsのcanary検査も、ランダムな値、期待値を質問に含めないこと、tool経由の取得を除くことを説明しています。後者のCodex部分は実モデル未実行と明記されています。以下は方式自体の新規性を主張するものではありません。

今回の検査では、次の条件をそろえました。

128bitのランダム値を生成し、検査する指示ファイルだけに置く。
質問には合言葉の名前を入れ、値は入れない。期待値を保存したファイルも対象プロジェクトの外に置く。
毎回新しいセッションを開始し、返答をローカルで完全一致比較する。
tool呼び出しが観測された場合は、正しい値が返っても判定保留にする。

通常のguidance設定を保持する一方、この検査プロセスではhooks・Apps・plugins・設定済みMCPなどを無効化しています。普段の全機能を有効にした環境と同一ではありません。 初版が調べるのは起動時の指示ファイル経路で、hookの配信、MCPによる引き継ぎ、compaction後の記憶は対象外です。

10月23日追記：実際のWindows導入障害を受けたv0.1.1

公開版を試した開発者から、Windows 11ではoffline testとprepareは成功したが、liveはOS制限で停止したという報告がありました。native Windowsが普段の作業環境という続報を受け、同じ公開版にshellを使わない起動とプロセス終了処理を追加しました。

Windows CIでは、公式Codex CLI 0.163.0の起動・設定読取・終了まで成功しました。これはモデルを呼ばない検査です。v0.1.1公開時点では認証済みWindowsでの合言葉応答は未確認でした。運営側のWindows live検証は引き続き未実施で、現在確認できる外部v0.1.4の1環境報告は上の追記を参照してください。Windows対応は実験版です。 Macの最終コードでは1回の合成live検査が11.876秒、RECEIVED、観測tool 0、6.1Sol/MAX、終了確認ありでした。こちらも運営側の検査で、外部利用実績ではありません。

Windowsでは下のPOSIXシェル例を使わず、PowerShellの初回と変更後の完全な手順を使ってください。v0.1.1で追加した変更は現行v0.1.4にも含まれます。共通のZIPとchecksumは下記です。Codex CLIは引き続き0.163.0以上が必要で、ツールが自動更新・ログインすることはありません。

なお、組み立てた入力だけの確認なら公式のcodex debug prompt-inputがあります。以下のキットは、読込対象とバイト推定を分けて確認し、必要なら実際の応答と変更前後の比較へ進むために使います。

公開プロジェクトで確認できた、二つの区別

この検査を使う理由は、ファイルの存在やタスク成功だけでは、起動時に何が届いたかを切り分けられないためです。関連する公開のやり取りでは、次の改善が確認できました。

設定ファイルがあることと、その設定が有効なこと。 Relay v0.1.2／Codex0.163.0で測ったプロジェクト設定の差を報告したところ、Agent Guildの作者が読込漏れを確認し、trustedなプロジェクト設定を反映する修正をv1.9.1で公開しました。作者自身の確認はCodexのdebug commandによるもので、Relayを実行したという報告ではありません。測定条件と結果。
タスクが通ることと、指示ファイルの効果を切り分けること。 pytest-codexでは、タスクの設問にも実行コマンドが書かれていた検査について指摘した後、作者が設問にコマンドを含めない別の例と、検証範囲の説明を追加しました。これは作者自身の1回の挙動検査と保存記録の再検証であり、Relayの実行や、指示の全文受領・遵守の証明ではありません。

この二つの上流変更を、外部の二人がRelayを使った証拠としては扱いません。自分の環境で再利用するときも、nativeのファイル選択、別のローカルbyte見積り、合言葉の受領、実タスクの成否を分けて残します。実行前にコードを確認したい場合は、v0.1.3の確認箇所・コマンド別の入出力・全23ファイルのハッシュを参照できます。

自分のプロジェクトで試す

この条件確認と変更前後の比較を繰り返すため、MITライセンスの小さなCLI、Agent Relay Check v0.1.4にまとめました。合言葉を使うlive検査には、Node.js 22以上、認証済みCodex CLI 0.163.0以上、macOS/Linux（native Windowsは実験対応）、利用するモデルへの既存のアクセス権と利用枠が必要です。既定はgpt-6.1-sol / MAXで、別のモデル・推論設定は冒頭の運営検証と外部報告の範囲を確認してください。live検査は既存Codexアカウントの利用枠・課金を使います。他のモデルへの自動切り替えはしません。

24ファイル・54,863 bytesのv0.1.4 ZIPを展開し、agent-relay-checkディレクトリで実行します。SHA-256も公開しています。npm依存パッケージやグローバルインストールは不要です。

まず指示ファイルを編集せずに検査する：`inspect`

展開したキットのディレクトリで、確認したい起動位置を指定します。Node.js 22以上とインストール済みCodexが必要です。

node cli.mjs inspect --project "/absolute/path/to/your project"

合言葉の追記やモデルの応答は不要で、モデルturnを要求せずにJSONをローカルへ出力します。ただしCodexを起動して新しい一時セッションを初期化するため、サービスへの通信やCodex自身の通常のローカルメタデータ書込はあり得ます。オフライン検査という意味ではありません。読み込ませてよい指示を持つプロジェクトで使ってください。Relayが設定を自動修復したり、レポートを自動投稿したりすることはありません。

フィールド	分かること
`native_listed`	Codexの`thread/start.instructionSources`に、そのファイルのパスがあった。全文が入った証拠ではない
`estimated_status`、`examined_bytes`	ローカルのファイルと、検出したstable Codex 0.163.0または0.164.0の読込方式から推定した状態とバイト数。Codexが返したバイト数ではない
`status: INSPECTED`	対応する推定とCodexのパス一覧が一致した。合言葉の受信・指示の遵守の合格ではない
`status: INCONCLUSIVE`	バージョン、設定の出所、読込対象の不一致、途中のファイル変更などで対応する結論を出せない

運営側の合成プロジェクトでは、上限128 bytes、親40 bytes、子200 bytesにすると、Codexの一覧には親と子の両方がありました。一方、ローカル推定では子は88 bytesまでのTRUNCATEDです。親だけで上限を使い切る場合と、子に空のoverrideがある場合は、異なる理由で同じパス一覧になりました。対応する2版ごとに実行した5条件の実測と制約を公開しています。これも外部の利用実績ではありません。

10月24日追記：globalのリンク切れでも`INSPECTED`になった

同じv0.1.3を使い、macOS／Node22.23.4／公式stable Codex0.164.0で、合成のglobal AGENTS.mdを4通りに変えました。プロジェクト側は毎回同じ30 bytes、project上限128 bytesです。専用の一時設定を使い、普段の設定や認証情報はコピーしていません。

合成global `AGENTS.md`の置き方	`other_native_source_count`	全体の`status`
通常ファイル	1	`INSPECTED`
同じ内容を指すsymlink	1	`INSPECTED`
同じsymlinkの参照先の本文を更新	1	`INSPECTED`
存在しない参照先を指すsymlink	0	`INSPECTED`

4条件ともモデル要求0回、projectの別ローカル推定は30 bytes、起動した2プロセスの終了確認ありでした。通常のCodex初期化に伴う通信・メタデータ書込はあり得ます。公開した再現手順そのものでも、同じ4条件を確認しました。8種類の検査や外部利用8件という意味ではありません。

INSPECTEDだけを見ても、期待するglobalな指示が存在・受領されたとは判断できません。 このfixtureは、既知のuser-config層だけが外部source数へ寄与する条件です。通常の環境で件数だけから特定のglobalファイルを同定することもできません。参照先の本文を更新しても件数は1のままで、内容の版や全文が届いた証拠にはなりません。

今回の検査はglobal本文・参照先・受領・遵守を検証しておらず、Windowsや別のCLI版への一般化もしていません。4対照の実測表、制約、隔離した再現手順をまとめています。dotfilesの移動や設定変更の前後を比べる場合も、statusだけで済ませず、自分が確認したいフィールドと、別の受領検査を分けて残します。

現行v0.1.4のバイト推定はstable Codex 0.163.0または0.164.0に対応し、検出した読込方式をレポートのbasisに記録します。新しい版やalpha版、未知の設定レイヤーなどは、自動的に同じ方式と見なさずINCONCLUSIVEにします。対象は単一のローカル起動環境です。外部の指示パスは件数だけを記録し、全文やホームディレクトリのパスをレポートへ入れません。

inspectの終了コードは、検査完了0、判定保留3、コマンドエラー1です。これは以下のlive検査の結果とは別です。

合言葉が実際に返るかを、自分のプロジェクトで確認する

以下はmacOS/LinuxのPOSIXシェル向けで、自分のプロジェクトを1回のモデル呼び出しで検査する手順です。Windowsでは前節のPowerShell手順を使います。準備と比較はオフラインです。

キットのagent-relay-checkディレクトリから、作業用の一時ディレクトリを新しく作ります。RELAY_WORKが検査対象プロジェクトの外を指すことを確認し、以降も同じターミナルで続けてください。期待値や結果を対象プロジェクト内に置くと、起動時の指示以外から値を読めてしまうためです。この手順は共通のv0.1.4向けです。元のv0.1.0・v0.1.1・v0.1.2・v0.1.3 ZIPは別URLで保全しています。

RELAY_WORK="$(mktemp -d "${TMPDIR:-/tmp}/agent-relay.XXXXXX")"
node cli.mjs prepare --keys project_probe --out "$RELAY_WORK/before"

生成された$RELAY_WORK/before/instruction.mdの検査ブロックを、確認したい既存のAGENTS.mdの末尾へ追記します。既存の内容を置き換えないでください。challenge.jsonは答えを保持するため、対象プロジェクトの外に残し、エージェントへ貼り付けません。

node cli.mjs run \
  --project "/path/to/your-project" \
  --challenge "$RELAY_WORK/before/challenge.json" \
  --out "$RELAY_WORK/result-before" \
  --live

/path/to/your-projectは、確認したい起動ディレクトリに置き換えます。子の指示を確認するなら子を指定します。このrun --liveが1回のモデル呼び出しです。--outは親が存在する新規ディレクトリで、同名の結果ディレクトリを使い回しません。challengeと出力先は、シンボリックリンクを解決した後も対象プロジェクト外である必要があります。

事前確認で止まった場合も、結果ディレクトリが確保済みになることがあります。原因を直して再試行するときは新しい--outを使ってください。事前確認エラーを「合言葉が届かなかった」とは数えません。検査を終えたら追記したブロックだけを取り除きます。続けて設定変更前後を比較する場合は、次節の新しいブロックへ置き換えます。

既存の認証を利用し、指示内容はモデル入力になります。送信してよい指示だけを対象にしてください。CLIは指示ファイルやグローバル設定を自動修復しません。

結果の読み方

結果	観測したこと
`RECEIVED`	新規・完了済みセッションで、tool呼び出しを観測せず、合言葉が完全一致した
`NOT_OBSERVED`	利用可能な返答はあったが、値がnullまたは不一致だった
`INCONCLUSIVE`	tool取得、timeout、形式不正、turn未完了、プロセス終了未確認などがあった

NOT_OBSERVEDには、届いていてもモデルが無視・失念した場合を含み得ます。RECEIVEDも、当該の合言葉を返せたという証拠であり、ファイル全文の遵守や安全性を保証しません。

終了コードは順に0、2、3です。コマンドや事前確認のエラーは1です。CIに組み込む場合は、2と3を同じ「指示が未配信だった」と扱わないようにします。

設定を変えたあとに、同じ検査を使い直す

同じターミナルのRELAY_WORKを使い、新しい合言葉を生成します。前回の検査ブロックが残っていればそれだけを置き換え、外してあるなら新しいブロックを追記します。同じproject_probeという名前と起動位置を保ち、別の出力先で実行します。

node cli.mjs prepare --keys project_probe --out "$RELAY_WORK/after"
# "$RELAY_WORK/after/instruction.md" の検査ブロックに置き換えてから実行
node cli.mjs run \
  --project "/path/to/your-project" \
  --challenge "$RELAY_WORK/after/challenge.json" \
  --out "$RELAY_WORK/result-after" \
  --live
node cli.mjs compare \
  --before "$RELAY_WORK/result-before/report.json" \
  --after "$RELAY_WORK/result-after/report.json"

この再検査でモデル呼び出しがさらに1回、初回と合わせて2回になります。prepareとcompareはモデルを呼びません。比較には状態の変化と、CLI・モデル・推論設定・ツールのversion差が出ます。何を変更したかは別途記録してください。差が出たことだけでは原因の確定にはなりません。別の比較を始めるときは、新しい一時作業ディレクトリを作ってください。

自分の指示ファイルを触らず試す別の方法として、node examples/override.mjs --out "$RELAY_WORK/demo" --liveも用意しています。Gitが必要で、4回のモデル呼び出しを伴います。同一の新規プロジェクト内の通常・同階層override・除去後・指示なしを比べます。その4条件の実測を公開済みです。冒頭の「子の空override」の3条件、および上記の自分のプロジェクトでの初回1回とは別のデモです。

試した場合は、CLI version、OS、起動位置が親か子か、結果の状態、変更した条件を教えてもらえると、こちらの環境だけの結果か比較できます。report.jsonには合言葉の原文、会話、プロジェクトパス、設定本文を含めませんが、共有前に内容を確認してください。秘密や普段の指示ファイル全文を送る必要はありません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up